forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Wrong indices of an array of derived type in the debugger

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
StamK



Joined: 12 Oct 2016
Posts: 159

PostPosted: Mon Jul 08, 2019 12:09 am    Post subject: Wrong indices of an array of derived type in the debugger Reply with quote

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
View user's profile Send private message
StamK



Joined: 12 Oct 2016
Posts: 159

PostPosted: Mon Jul 08, 2019 12:46 am    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon Jul 08, 2019 3:20 am    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon Jul 08, 2019 10:16 am    Post subject: Re: Reply with quote

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
View user's profile Send private message
StamK



Joined: 12 Oct 2016
Posts: 159

PostPosted: Mon Jul 08, 2019 11:43 pm    Post subject: Reply with quote

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
View user's profile Send private message
StamK



Joined: 12 Oct 2016
Posts: 159

PostPosted: Mon Jul 08, 2019 11:49 pm    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Tue Jul 09, 2019 12:31 pm    Post subject: Reply with quote

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
View user's profile Send private message
StamK



Joined: 12 Oct 2016
Posts: 159

PostPosted: Tue Jul 09, 2019 12:37 pm    Post subject: Reply with quote

As I said, I cannot reproduce it in a simple example, so of course what you did will not show it. Very Happy
Back to top
View user's profile Send private message
StamK



Joined: 12 Oct 2016
Posts: 159

PostPosted: Wed Jul 10, 2019 11:18 am    Post subject: Reply with quote

Robert: I sent you yesterday an email with the files to download from wetransfer. Thanks
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
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