Unable to set breakpoint when using checkmate

I've started to put the /checkmate option into my debug builds but I've had to back it out for the moment as when I specify it I lose the ability to breakpoint 'some' functions.

The only option is to set a breakpoint on the last line of the routine. I also have /NO_TRUNCATE set. I'm not sure if this is interfering with it. When I remove checkmate the ability to set breakpoints is available again.

I'm using 8.61.

I can provide more detail if required (currently waiting on a test run to complete).

Regards

Ryan

Ryan

The first thing to check is that you have rebuilt all of your code using /checkmate (or whatever current debugging options you are using). If a breakpoint can't be set then it usually means that there is no internal debugging code at this point.

The internal debugging code is provided by FTN95 during compilation and is used by SDBG64 whilst debugging.

If that does not solve the problem then please report which version of the debugger you are using and whether you are debugging directly (by running SDBG64.exe) or if you are using the debugger that is built into Plato and run with the Plato option to 'Integrate with SDBG/SDBG64'.

Sorry for the extremely slow reply.

The debugger is launched using sdbg64 name.exe from the command line.

It self identifies via the help / about popup as 'Win64 version 8.62'.

The compiler is 8.62.1.

Flags used are - /64 /debug /NO_TRUNCATE /CHECKMATE

Ryan, please update the debugger (and, optionally, the compiler) to 8.64. The downloads are in the sticky post at the top of the Support forum.

If you see the problems persist even after the update, please provide a 'reproducer'.

I wasn't aware of those links, thank you.

That hasn't solved the problem though.

I will try reducing it down to the function that I cannot breakpoint and let you know.

I do worry that because of the nature of this codebase (badly typed, globals everywhere) the problem will go away.

Quoted from Ryan I do worry that because of the nature of this codebase (badly typed, globals everywhere) the problem will go away.

Those attributes should have no bearing on the subject of this thread (Unable to set breakpoint when using checkmate). If you can compile and link the program, in the debugger you should be able to set breakpoints, etc.

The reason I think that is because it varies from one function to the next, some have no ability to set breakpoints (nor an indicator in the 1st column) except for the last line and some are fine.

Something in the syntax is perhaps causing the parsing to break.

Have you tried using only /debug? That is, not using /check or /checkmate?

Yep, as I said at the top, it goes away without those options and breakpointing works.

I've managed to isolate it to the point that the inclusion of an IF statement causes the ability to debug via breakpoint to disappear when using /CHECKMATE.

! Compiling with this does not allow breakpointing in CheckForSpace when the conditional is not commented out.
! ftn95 breakpoint.for /64 /debug /NO_TRUNCATE /CHECKMATE /LINK

! Removing the /CHECKMATE statement (as follows) enables debugging via breakpoints.
! ftn95 breakpoint.for /64 /debug /NO_TRUNCATE /LINK

! Code is tested via 'sdbg64 breakpoint.exe'

      SUBROUTINE CheckForSpace(instring)
        CHARACTER*120 instring

        ! Commenting out this conditional (leave the print) allows debugging of the print statement.
        IF (instring(1:1).NE.' ') THEN
            print *, 'Starts with space.'
        ENDIF
      END

      program main
        call CheckForSpace( 'a' )
      end program main

If, despite not being able to set breakpoints on source lines in the subroutine, one steps into the subroutine, SDBG64 does display an error in the program: the actual string argument is shorter than the string length of the dummy argument.

The breakpoint problem does not occur with 32-bit compilations using /CHECKMATE.

Please ignore the bad code. It is a bodged example. It does demonstrate though that the error line is not stopped, just a break at the end of the function. In large functions (of which we have quite a few of > 1000 lines (not my fault)) it is very hard to figure where the error is.

The bug cannot be diagnosed in 32 bit as the debugger runs out of memory on this codebase and fails with an out of memory error. But that is an entirely different issue.

Ryan, I had no intention of criticizing your example code. I pointed out the interface mismatch since the occurrence of multiple errors in the same lines of code often makes the diagnosis more difficult and confusing than when we have only one error.

Ryan

There is an ongoing issue with FTN95 that might relate to your problem.

Please look out for a new interim release of FTN95 that hopefully will be announced within the next week or so.

Ryan

A new version of FTN95 is now available for download. See https://forums.silverfrost.com/Forum/Topic/3780.

Thank you Paul. I've only just seen this.