Strange behaviour of sdbg64 8.50: cannot set breakpoints ...

When debugging the following program I observed some obscurities with respect to sdbg64 one of which is that I cannot set any breakpoint.

Program name: test_clearwin_info.for

      INCLUDE <WINDOWS.INS>
      integer*2 IRXSCR0,IRXSCR1
      IRXSCR0=CLEARWIN_INFO@('SCREEN_WIDTH')
      IRXSCR1=CLEARWIN_INFO@('SCREEN_DEPTH')
      write(*,*) 'IRXSCR0=',IRXSCR0,'IRXSCR1',IRXSCR1
      end

Build comand: ftn95 test_clearwin_info.for /64 /debug /link

Debugging the executable built with the command mentioned above via sdbg64 8.50 results in following obscurities: Source file test_clearwin_info.for is not shown Entering CTRL-G + character '4' makes the debugger show the source file Trying to set a breakpoint via F2 in line 3,4,5 results in error message 'This line cannot be breakpointed' Having selected menu Window, submenu Common Block makes sdbg64 hang

Using sdbg64 8.40 instead of 8.50 the source window is shown and I can set breakpoints in the lines mentioned above. However, the Common Block submenu behaves strange as described above. Moreove I observed that the Common Block submenu does not appear in the Window menu of the 32 bit version of sdbg (8.40 and 8.50).

Regards, Dietmar

There is something very strange going on there. I can have it happen but it happens in various versions of sdbg64 - (8.50 and 8.30 for example). You say you can get it to work with version 8.40 but I couldn't.

More investigation required.

Robert,

I am a little bit confused now.

I could set breakpoints when using ftn95/sdbg64 version 8.30 and 8.40. I could **not **set breakpoints when using ftn95/sdbg64 version 8.50.

Regards, Dietmar

Robert,

here one interesting observation:

in the DOS window which I used for building test_clearwin_info.exe with respect to ftn95 version 8.50, environment variable SOURCEPATH was not set. Hence I set it to the absolute path of the directory the source to be compiled was located in. Now when I executed

sdbg64 test_clearwin_info.exe

the source was displayed as expected and I could set breakpoints.

This was even true if I 'unset' SOURCEPATH again (via command 'set SOURCEPATH=').

I have no explanation for this.

Regards, Dietmar

Dietmar

It is quite possible that the value of SOURCEPATH is only relevant at compile time. I would need to check this out.

If it is then, once you have built your executable, the value of SOURCEPATH will make no difference.

However, still there is the problem that after my first build the problems metioned occurred for ftn95 and sdbg64 version 8.50 and not for 8.40, isn't it?

Regards, Dietmar

I forgot to say in my last post that for version 8.40 variable SOURCEPATH has not been set before starting the first build.

Regards, Dietmar

This behaviour is due to a regression in FTN95 at v8.50.

Please try the patched version of FTN95 that you can download via the following link. This is only for users of FTN95 v8.50.

https://www.dropbox.com/s/jy6qnixyoyv3plp/ftn95.zip?dl=0

Paul,

thanks for the new version (8.51.0) of ftn95.exe. Now in sdbg64 the sources of my test sample are shown as expected without variable SOURCEPATH having been set and I can set breakpoints, as well.

There is still another question I raised which, however, is of minor importance to me: what about menu Window, submenu 'Common Blocks' in sdbg64? I currently do not know its meaning and sdbg64 hangs if I select it.

Regards, Dietmar

Dietmar

It does not work for me either. I will make a note of this.

Dietmar, in SDBG64 version 8.40.1, the Common Blocks pop up simply shows the range of addresses occupied by common blocks, if any are declared. After viewing that pop up, I have no problems with setting break points, stepping through the program and viewing variable values.

With most compilers, the addresses of common blocks may be obtained by telling the linker to produce a map file. SLINK64, on the other hand, will not assign addresses to common blocks at link time. Thus, being able to obtain the addresses of common blocks can be useful at run time when debugging at the assembler level.

PS: I can reproduce the problem described by Dietmar when I start a program *that does not contain common blocks *in SDBG64 8.40.1 and click on Window->Common Blocks.

mecej4, Paul,

thanks for the information.

Now I have introduced a common block to my test sample (adding line

COMMON /SCREEN_INFO/ IRXSCR0,IRXSCR1

to the code of test_clearwin_info.for); compiling/linking with ftn95 (version 8.51.0) works and I can see the Common Block Window as described by mecej4. Now if I decomment the common block line in the code again and compile/link again, sdbg64 works with respect to the Common Block menu: no hanging any more if I select the common block menu. This makes me astonish, for the original application when comiled/linked for the first time had hung in this situation.

Regards, Dietmar

I think it is specific to programs that have no common blocks.

Hi folks. I'm running v8.50 and am also unable to set breakpoints in sdbg64.

Aside from this, when I open the debugger, the code window is scrolled way down to line 1056 (when the f95 file itself has 322 lines).

I downloaded the FTN95.zip that Paul uploaded, recompiled, and upon running the program in the debugger, was met with an immediate crash.

I am inexperienced with FTN95 so would appreciate some guidance!

Alistair

Can you try this sdbg64 to see if it solves your crash:

https://www.dropbox.com/s/szr6plultrp6i5k/sdbg64.zip?dl=0

Thanks for uploading so quickly; unfortunately exactly same issues: falls over with updated FTN95, no breakpoints with older FTN95.

Is there a possibility we could have the executable to try? We don't need the source, just be able to run it in the debugger. If you can then either email it or a link to it to ftn95@silverfrost.com (you will get a bounce message if it contains an executable... but we will receive it).

Just an update: Silverfrost provided me with patched versions of FTN95 and sdbg64 and, once I'd recompiled, I was able to run the debugger with correct line numbers and breakpointing.

There's one other issue though: seems I can't click through to subroutines in other modules from the main program module. To work around this, it is possible to search for the subroutine and set breakpoints in the new code window, as before.

You should be able to 'step into' subprograms provided they have been compiled using /DEBUG or an option the includes /DEBUG.

Would it be possible for us as well to have the latest sdbg64 and ftn95? We are having serious issues when debugging large files - it appears to go after the end of the file. I think it used to be a problem in older versions but I thought it was fixed?