Welcome to our forums
When SDBG starts, I get an error...
typing:
SDBG progname.exe
gives:
Failed to open file progname.exe, code = 2 Failed to open file progname.exe, code = 2
but running progname.exe works.
Anyone know what's causing it?
TIA
K
Some more information...In SDBG I get this:
Access violation The instruction at address 10004a62 attempted to write to location 00001104
100047e6 load program(<ptr>constAchar,<ptr>constAchar)[+27c] 100094fb sdbg_main [+0cd3] 00401000 main [+0076]
If that helps at all!
K
I sometimes get this kind of error and it goes away if I repeat the command a few times.
Otherwise, try a complete rebuild and/or use a new DOS box. Also look at the Task Manager to check that the last run has fully terminated.
OK, I've isolated the problem. It's a call to DOWNLOAD@ that fails with an access violation:
Exception 0x000006c5, and the crash is in kernel32.dll.
But only when I run it via the debugger. In ordinary running, it works OK.
Any ideas?
K
If you know the routine that leads to a call to kernel32.dll then you can check its arguments before the call.
If you cannot locate any errors in your code then you might be able to bypass the problem when debugging by isolating this part of the code so that this part runs in 'release' mode (i.e. without any debugging options).
You can do this by using something like OPTIONS(-debug) before the code for the given routine or by putting it in a different file that has appropriate compiler command line args.
Quoted from PaulLaidler If you know the routine that leads to a call to kernel32.dll then you can check its arguments before the call.
If you cannot locate any errors in your code then you might be able to bypass the problem when debugging by isolating this part of the code so that this part runs in 'release' mode (i.e. without any debugging options).
You can do this by using something like OPTIONS(-debug) before the code for the given routine or by putting it in a different file that has appropriate compiler command line args.
Sorry, not sure I follow what you mean. Are you saying that there's a flag that can be used to detect if the app is being RUN via the debugger (as opposed to a source file having been compiled with debug, which I know how to do) so it can 'skip past' the offending code? If yes, what's the syntax? I can't see 'OPTIONS(-debug)' described in the help system.
K
OPTIONS is an FTN95 directive that you can include in your Fortran code.
It allows you to set compiler command line switches in your code.
You will find it described under 'Complier directives' in the help file.
Quoted from PaulLaidler OPTIONS is an FTN95 directive that you can include in your Fortran code.
It allows you to set compiler command line switches in your code.
You will find it described under 'Complier directives' in the help file.
OK, found that, thanks, but I don't understand how it helps!
The problem is that even when the routine that calls DOWNLOAD@ is not compiled with debug, when the application is run under SDBG, it crashes in that routine. (Compiling the routine with /debug allowed me to see that it was the call to DOWNLOAD@ that was causing the grief.)
So, what I really need is an inline test that says something like
'IF(.NOT.RUN_BY_SDBG) THEN'
Is there something like that available?
K
Not that I know of.
Quoted from PaulLaidler Not that I know of.
OK, 😦, so I guess the only approach is to use a command line switch and a batch file:
RUN_SDBG.BAT: sdbg %1 /p /sdbg %2 %3 %4 %5
And then in my app: call command_line(CH) ISDBG = index(CH,'/sdbg') IF( ISDBG.GT.0 ) THEN CH = CH(ISDBG+5: ) END IF
and surround any 'dodgy code' with: IF( ISDBG.EQ.0 ) THEN . . END IF
Should that work?
K
EDIT: Yes it does - very nicely! 😄