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 

SDBG64 displays incorrect variable values

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



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon Apr 24, 2017 4:09 pm    Post subject: SDBG64 displays incorrect variable values Reply with quote

When the test program below is compiled with /64 /checkmate and run in SDBG64 and run until Line-16, the first executable statement in the subroutine, the variables pane shows n = 4214920, and indi = [37813896, 0, 4214920, 0, 37813916]. Note that the third element has the same value shown as for n. Hovering the mouse pointer over 'n' in the source line also displays the incorrect value 4214920.

Code:
program tst
implicit none
integer ind(5),i
!
do i=1,5
   ind(i) = i*i
end do
call sub(ind,5)
print *, ind
end program tst

subroutine sub(indi,n)
implicit none
integer n,indi(n)
!
indi(1:n) = indi(1:n)+2
return
end subroutine sub

If the EXE is run from the command line, the output results are correct, so I suspect that it is just the variable display in the debugger that is a bit mixed up.

The entire problem disappears if the subroutine is CONTAINed in the program.
Back to top
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 444
Location: Manchester

PostPosted: Tue Apr 25, 2017 10:39 pm    Post subject: Reply with quote

Thanks for this report. Curiously it shows the correct values if just using /debug
Back to top
View user's profile Send private message Visit poster's website
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sun Apr 30, 2017 10:46 pm    Post subject: Reply with quote

There are several other problems with the debugger. Hopefully they are already fixed and we can see new debugger soon, if not here is a demo reproducer

Funny is that probably only two people in the entire world are using debugger, me and mecej4, I may miss one more, all others are just super Pros without it, the masters of extra Print* for debugging. Or are using police sniffing dogs trained on Fortran bugs. Sorry, but I am running out of more reasonable clues on why they masochistically like troubles. The developers don't use it too, they program everything in C my educated guess is. Are C debugges that bad so no one use them? Clearly there is no culture of using debugger

1) In this code this error is still there even with /debug
Code:
integer iVar(3)

 iVar(1) = 1
 iVar(2) = 2
 A=1.

 call subr(A, iVar,3)
 print *, A, iVar

end

subroutine subr(A,iVar,N)
 integer iVar(N)
 A=2
 iVar(1) = iVar(2) + iVar(3)

 B=3

end subroutine




Small overall view problems: Why two lines are in red by the way? And what the red lines are showing after the program ended? What purpose is for wide gray border on the top, this has to be eliminated and the window moved up to see its bottom line which are jammed (not shown here). Shown here is only 1/3 of the window (monitor width is 3840) i can not decrease in size.

2) And if this code is compiled with /undef the whole subroutine content gets messed up immediately even before doing anything:
a) on entrance in the subroutine the A variable shows some crazy value
b) being stopped on processing of undefined variable the debugger tricks programmer and jumps from offending line few lines down as if variable B is undefined not iVar(3)
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon May 01, 2017 3:21 am    Post subject: Reply with quote

SDBG64 does have odd UI behavior in some respects. As Robert wrote, don't use /undef (or /checkmate) in combination with /debug (until the bug is fixed).

The gray "border" that you wrote about is really a portion of the "canvas", i.e., background on which the source, stack and variable "panes" are placed. If you move the source pane down, you will see more gray space.

Program execution stops after the END statement is "executed". Unfortunately, if you don't have a blank line between the END of the main program and the SUBROUTINE line, the red bar will be on the SUBROUTINE line when execution is complete, which is confusing.

Choosing "Find Routine" pops up a small window with source file name and line number, but clicking on that line crashes SDBG64.

If you resize a source code pane, reducing the width causes strange behavior: characters beyond the right edge of the narrowed pane are wrapped over to the next line, but the first few wrapped characters remain hidden. You may also see the wrapped characters mixed up with the pre-existing characters on that next line.

My wish list: 1. Being able to restart and continue.
2. File->Open should do something.
3. Show X87 and SSE registers in Registers, by default or if requested.


Last edited by mecej4 on Mon May 01, 2017 9:59 am; edited 1 time in total
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Mon May 01, 2017 7:54 am    Post subject: Reply with quote

Meces4,

Do you see double red line ? May be this is the issue with my wide 4k monitor only, SDBG does not calculate line length correctly. When I resize the main source window just little bit the double red line immediately disappear.

Yes, I also see what you say when the source text wraps incorrectly if you decrease windows width shorter then the text length

Additional details: my compilation options were either

ftn95 bbb.f95 /64 /debug /link or
ftn95 bbb.f95 /64 /undef /link

so I did not use /undef and /debug simultaneously, and these bugs are still there. Do you see and confirm these bugs ?

Gray top canvas under menu can be hopefully removed if GUI was done using Clearwin+, I have all my codes without such wide border. Or at least the depth of source text window adjusted correctly, otherwise I see at the bottom of the debugger that the debugging source window does not fit the frame %fr defined by its wrong dimensions almost exactly of the size of gray border on the top. The %bx where the cursor red line number is displayed is cut

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