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.

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.

Thanks for this report. Curiously it shows the correct values if just using /debug

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

   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:

1. on entrance in the subroutine the A variable shows some crazy value
2. 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)

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.

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