|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
Clay
Joined: 20 Mar 2014 Posts: 23
|
Posted: Tue Oct 27, 2020 9:55 pm Post subject: Spurious Error 15 in debugger |
|
|
I have a problem that has started happening in the new v8.61 which did not happen in v8.50. In fact, this problem only happens in v8.61 DEBUG compiles (FTN95/windows/FULL_DEBUG/UNDEF/BINARY). The behavior is part of a large complex program not easy to put into a small test program.
I have a subroutine call with seven arguments: one INTENT(INOUT) and six INTENT(OUT) arguments. When running in the Silverfrost debugger, I get "Error 15, Attempt to access undefined argument to routine" on the line that calls the subroutine.
1st attempt to fix is to pre-define the arguments - even though that shouldn't be necessary for INTENT(OUT) arguments - but this made no difference. Still get the error.
2nd attempt was to omit the declarations of intent in the subroutine. This was done out of desperation, but it did result in a change: Now Error 15 is thrown on the first executable line of the subroutine instead of on the call statement. In other words, now instead of dying before entering the sub, I can enter the subroutine and die immediately.
The problem is that I can't understand why I'm crashing on the first line. If the signature of my subroutine was:
MySub(x1_inout, x2_out, x3_out, x4_out, x5_out, x6_out, x7_out)
then the first line of the subroutine is
x5_out = .false.
so I'm getting an "undefined argument" error when trying to assign a value to the argument!
Any advice or suggestions on what may be causing the problem and what can be done to fix it? This behavior makes it tempting to go back to the previous version of the compiler!
Thanks in advance. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Tue Oct 27, 2020 11:05 pm Post subject: |
|
|
I suggest that you try the version 8.66 of the compiler (see http://forums.silverfrost.com/viewtopic.php?t=4245 ).
You may also attempt to compile and run with just /debug (i.e., without /undef, etc).
If the problem remains, please provide a reproducer or at least show us the actual lines of code at issue. Your verbal descriptions are too abridged to enable a diagnosis of the causes of the error. The following test code, which I wrote based on your description, runs without error messages.
Code: | program debunk
implicit none
logical :: x1, x2, x3, x4, x5, x6, x7
!
x1 = .true.
call MySub(x1, x2, x3, x4, x5, x6, x7)
print *,'After call, x1 = ',x1
end program
subroutine MySub(a, b, c, d, e, f, g)
logical, intent(in out) :: a
logical, intent(out) :: b, c, d, e, f, g
!
e = .false.
if(a)then
a = .false.
b = .true.
endif
return
end subroutine |
|
|
Back to top |
|
|
Clay
Joined: 20 Mar 2014 Posts: 23
|
Posted: Wed Oct 28, 2020 3:25 pm Post subject: More info |
|
|
Thank you for the response. Downloading the latest compiler and debugger does not change the behavior.
I need to emphasize: There's nothing wrong with the code as it has been running for a long time - this is not new code I'm developing and testing. It was able to run and be debugged in v8.50. The issue is that when I upgraded to v8.61 I can no longer run my code in the debugger.
The code you provided is basically what I've got, though the data types aren't all logicals and there are some more layers. Below is a sketch of what it looks like. A lot of stuff is omitted, but I hope this is less abridged and will allow some diagnosis. My main program calls subroutine read_file and the debugger crashes where indicated.
Thanks in advance for any insights. This problem is preventing my organization from upgrading to the new compiler!
Code is too long to fit in a single post. I'll post "code" in subsequent post(s) |
|
Back to top |
|
|
Clay
Joined: 20 Mar 2014 Posts: 23
|
Posted: Wed Oct 28, 2020 3:32 pm Post subject: Ex Code 00 |
|
|
module MyModule
use OtherModule ! <-- defines MyTYPE
type MyOtherTYPE
integer :: ThereAreManyVars
end type MyOtherTYPE
type(MyOtherTYPE), dimension(:), pointer :: compdat => null()
subroutine read_file()
type(MyTYPE) :: info
logical :: error
character(len=80) :: tag
character(len=80) :: starttag
logical :: endtag
character(len=80), dimension(1:2,1:20) :: attribs
integer :: noattribs
character(len=200), dimension(1:100) :: data
integer :: nodata
logical :: has_compdat
has_compdat = .false.
allocate(compdat(0))
call read_00(info, tag, endtag, attribs, noattribs, data, nodata, &
compdat, has_compdat )
end subroutine read_file
subroutine read_00(info, tag, endtag, attribs, noattribs, data, nodata, &
dvar, has_dvar)
type(MyTYPE) :: info
character(len=*), intent(inout) :: tag
logical, intent(inout) :: endtag
character(len=*), dimension(:,:), intent(inout) :: attribs
integer, intent(inout) :: noattribs
character(len=*), dimension(:), intent(inout) :: data
integer, intent(inout) :: nodata
type(MyOtherTYPE), dimension(:), pointer :: dvar
logical, intent(inout) :: has_dvar
integer :: newsize
type(MyOtherTYPE), dimension(:), pointer :: newvar
newsize = size(dvar) + 1
allocate( newvar(1:newsize) )
newvar(1:newsize-1) = dvar
deallocate( dvar )
dvar => newvar
call read_01( info, tag, endtag, attribs, noattribs, data, nodata, &
dvar(newsize), has_dvar )
end subroutine read_00
subroutine read_01( info, starttag, endtag, attribs, noattribs, data, nodata, &
dvar, has_dvar )
type(MyTYPE) :: info
character(len=*), intent(in) :: starttag
logical, intent(inout) :: endtag
character(len=*), dimension(:,:), intent(inout) :: attribs
integer, intent(inout) :: noattribs
character(len=*), dimension(:), intent(inout) :: data
integer, intent(inout) :: nodata
type(MyOtherTYPE), intent(inout) :: dvar
logical, intent(inout) :: has_dvar
character(len=80) :: tag
call getInfo( info, tag, endtag, attribs, noattribs, data, nodata ) ! <--- Debugger throws Error 15 here as written
end subroutine read_01
end module MyModule
module OtherModule
type MyTYPE
integer :: ThereAreManyVars
end type MyTYPE
subroutine getInfo( info, tag, endtag, attribs, no_attribs, &
data, no_data )
type(MyTYPE), intent(inout) :: info
character(len=*), intent(out) :: tag
logical, intent(out) :: endtag
character(len=*), intent(out), dimension(:,:) :: attribs
integer, intent(out) :: no_attribs
character(len=*), intent(out), dimension(:) :: data
integer, intent(out) :: no_data
endtag = .false. ! <-- if don't declare arg intent, debugger throws Error 15 here
end subroutine getInfo
end module OtherModule |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Wed Oct 28, 2020 3:35 pm Post subject: |
|
|
Be warned that this forum only permits about 100 lines of code in a post, and the part beyond that limit gets removed.
Instead, zip up the sources, data and include files, if any, and instructions to build and run, upload the zip file to a cloud server such as Dropbox, make the uploaded file accessible to everyone, and post a link to it here. |
|
Back to top |
|
|
Clay
Joined: 20 Mar 2014 Posts: 23
|
Posted: Wed Oct 28, 2020 3:40 pm Post subject: Code is there |
|
|
My post "Ex Code 00" has everything I intended to post. Can you discern anything from that?
It will be very labor intensive to build an executable program that exhibits the problem - I'm just having a problem in a single subroutine of a large program.
Thank you for any help! |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Wed Oct 28, 2020 4:18 pm Post subject: |
|
|
Your two module sources are missing CONTAINS lines. I added those, and wrote the following trivial driver:
Code: | program tst
use MyModule
call Read_File()
end program |
When I compiled with /checkmate /64, using FTN95 8.66, and ran the program inside SDBG64, it completed normally. The conclusion is that the code that you supplied does not exhibit the abnormal behaviour that you described, so there is nothing that I can do until you provide a reproducer.
Consider the debugger as just another program. The input to it is the output of the compiler and the linker. For most inputs from a larger number of users, the debugger performs correctly and as expected.
One can admit that there are some inputs for which it fails; some of us have reported such failures, and those have resulted in fixes to the debugger and/or the compiler and linker.
Without a reproducible failure to work with, what can the developers do? |
|
Back to top |
|
|
Clay
Joined: 20 Mar 2014 Posts: 23
|
Posted: Wed Oct 28, 2020 4:33 pm Post subject: |
|
|
Thank you for the feedback, and as a developer myself I understand your point.
Nonetheless, as a paying customer it seems to me that the burden of effort belongs to the party who broke the debugger tool (Silverfrost) not me who is trying to create productive work using the tool.
What's a developer to do? Review the changes made between v8.50 and v8.61 to determine what would cause the debugger to throw spurious Error 15 on an assignment statement.
What's a customer to do? I think just revert to v8.50 and miss out on the features I was looking forward to in v8.61.
I'll try find some time to devote to troubleshooting the problem, creating demo program to share, etc. and will create a new thread if I can manage to do that.
I don't intend to be disrespectful or rude - I really do see your point. I hope you can see my perspective too. This is just yet another in a series of Silverfrost releases which place a burden of debugging and testing on me (customer).
Again just to emphasize: There's nothing wrong with my code - it has worked for a long time. The problem is in the latest compiler working with the latest debugger. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Wed Oct 28, 2020 4:53 pm Post subject: |
|
|
Clay, I am just a user, too, and the comments that I wrote are from that viewpoint. Let us wait and see if Silverfrost have other recommendations. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Wed Oct 28, 2020 7:36 pm Post subject: |
|
|
Clay
It makes all the difference if you can supply code for a working program that demonstrates the failure. If you are unable to cut it down, can you zip it up and put it on DropBox (say). |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Thu Oct 29, 2020 4:26 am Post subject: Re: |
|
|
Clay wrote: | There's nothing wrong with my code - it has worked for a long time |
This is a claim that can be challenged !
I extracted your code above and it did not compile. You have a problem that the module definitions are out of order, so if you change "OtherModule" and recompile, MyModule will see the old version.
As noted, you have also omitted "contains" from both modules.
Try and provide a reproducer for the behaviour you are reporting. Then both Silverfrost and other users may be able to assist. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|