|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Mon Apr 24, 2017 4:09 pm Post subject: SDBG64 displays incorrect variable values |
|
|
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 |
|
|
Robert
Joined: 29 Nov 2006 Posts: 445 Location: Manchester
|
Posted: Tue Apr 25, 2017 10:39 pm Post subject: |
|
|
Thanks for this report. Curiously it shows the correct values if just using /debug |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Sun Apr 30, 2017 10:46 pm Post subject: |
|
|
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 |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Mon May 01, 2017 3:21 am Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Mon May 01, 2017 7:54 am Post subject: |
|
|
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 |
|
|
|
|
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
|