|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Mon Jul 08, 2019 12:09 am Post subject: Wrong indices of an array of derived type in the debugger |
|
|
I am still trying to make a simple program to demonstrate this, but we have being having this problem for a long time, and basically we get what you see below (left part is the start, and right part is the end)
|
|
Back to top |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Mon Jul 08, 2019 12:46 am Post subject: |
|
|
Also wanted to add that we are allocating various variables of different sizes (eg. 0:41, 0:500), but after allocation, if we hover over the variable, we can see that the range is always
-2139062144:16843008 |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1892
|
Posted: Mon Jul 08, 2019 3:20 am Post subject: |
|
|
Based on your recent posts concerning /UNDEF and /INHIBIT_CHECK=10, I have constructed a short program to demonstrate a scenario where you may obtain such results.
The first output number, -2139062144, is Z'80808080', which is the bit pattern used to represent undefined variables when /undef is specified. If such an undefined value is passed as an argument to a subroutine whose code was not compiled with /undef, results such as those that you observed can be produced.
Take the following program units and put them into separate files. Compile the main program with /undef and the subroutine without /undef, link and run.
The main program:
Code: | program StamKBug
implicit none
integer idx
call sub(idx)
end program |
The subroutine:
Code: | subroutine sub(idx)
integer idx,i
do i=1,10
write(*,'(1x,i2,I12,2x,Z8)')i,idx,idx
idx=idx+1
end do
return
end |
|
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1892
|
Posted: Mon Jul 08, 2019 10:16 am Post subject: Re: |
|
|
StamK wrote: | Also wanted to add that we are allocating various variables of different sizes (eg. 0:41, 0:500), but after allocation, if we hover over the variable, we can see that the range is always
-2139062144:16843008 |
Again, this is only a single symptom of multiple errors in your program. The lower bound is Z'80808080', which stands for "undefined", if /undef was used when compiling. The upper bound is Z'01010100', which again indicates some sort of error.
Don't expect any resolution of the problems in your code through forum posts until you can supply a more complete description, a reproducer, or (if tolerable) the complete source code and build instructions.
When a program being investigated is very large, it is not productive to use /undef at the outset. Likewise, when there are program bugs present it is often useless to run the program in a symbolic debugger. As you have demonstrated, what the debugger shows you can be of limited use and may be quite confusing.
I find it more useful to use these steps when investigating large character mode programs:
1. Build and run the program without /check or /undef. Fix bugs as far as you can in order to get the program run to completion. The results may be incorrect, but at least the program runs.
2. Repeat with /check. Fix argument mismatches, incorrect file access and I/O statements, array bounds errors. Evaluate the results again.
3. Repeat with /undef. Many programs may work correctly even when undefined variables are present, so be cautious not to spend too much time with /undef, especially in the context of old programs from the mainframe era.
4. Profile the program and note which sections of code were not exercised. These sections may still contain bugs, and those bugs may only surface when different inputs are used several years later, so documenting the code and development of verification runs are important. |
|
Back to top |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Mon Jul 08, 2019 11:43 pm Post subject: |
|
|
Many thanks for that.
/CHECK gives exactly the same problems.
The program works fine (most of the time), but we do get the occasional, non-easily repeatable crash, and so we are trying to see if we can use /undef to find something. We used to use it a lot, but since the end of last year we basically gave up on it (because of the issues raised, some of which have just been fixed by Paul and Robert).
Now however we are a bit stuck and we need to get back to it.
Apart from the indices, there is another issue, but I cannot reproduce it in a simple example unless I give the whole program to Paul, which I think I may do. |
|
Back to top |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Mon Jul 08, 2019 11:49 pm Post subject: |
|
|
This is very strange.
I am now using the latest slink v1.48, and I don't get (in the large program) those strange indices any more, but now they are (0:0), even though I have done
ALLOCATE(SERS(0:NS))
where NS=50.
Very strange... |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1892
|
Posted: Tue Jul 09, 2019 12:31 pm Post subject: |
|
|
Since you show no supporting observations, I have to conclude: "Strange to you, unknown to the rest of us".
I have SLINK 1.47, which is the version that was released with FTN95 V 8.5. I do not have SLINK 1.48, and I do not know how to obtain it. If you still have an older version of SLINK than 1.48, please try to reproduce your findings with it.
I do not see any strange things with the 64-bit FTN95 V8.51/SLINK64 2.10 either.
Here is counter evidence:
Code: | program strange
integer, parameter :: NS = 50
integer, allocatable :: sers(:)
!
allocate(sers(0:NS))
print *,NS,allocated(sers)
end program |
I see in SDBG64 when the current line is Line-6:
Code: | SERS = INTEGER*4 (0:50) |
Last edited by mecej4 on Tue Jul 09, 2019 12:38 pm; edited 1 time in total |
|
Back to top |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Tue Jul 09, 2019 12:37 pm Post subject: |
|
|
As I said, I cannot reproduce it in a simple example, so of course what you did will not show it. |
|
Back to top |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Wed Jul 10, 2019 11:18 am Post subject: |
|
|
Robert: I sent you yesterday an email with the files to download from wetransfer. Thanks |
|
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
|