| View previous topic :: View next topic |
| Author |
Message |
KennyT
Joined: 02 Aug 2005
Posts: 318
|
 Posted: Mon Sep 12, 2011 8:27 pm Post subject: Wierd error starting SDBG |
 |
|
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 |
|
| Back to top |
|
 |
KennyT
Joined: 02 Aug 2005
Posts: 318
|
| Posted: Tue Sep 13, 2011 1:42 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8208
Location: Salford, UK
|
| Posted: Tue Sep 13, 2011 2:58 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
KennyT
Joined: 02 Aug 2005
Posts: 318
|
| Posted: Wed Sep 14, 2011 11:55 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8208
Location: Salford, UK
|
| Posted: Wed Sep 14, 2011 12:53 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
KennyT
Joined: 02 Aug 2005
Posts: 318
|
| Posted: Wed Sep 14, 2011 2:32 pm Post subject: Re: |
|
|
| PaulLaidler wrote: | 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 |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8208
Location: Salford, UK
|
| Posted: Wed Sep 14, 2011 4:16 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
KennyT
Joined: 02 Aug 2005
Posts: 318
|
| Posted: Wed Sep 14, 2011 4:45 pm Post subject: Re: |
|
|
| PaulLaidler wrote: | 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 |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8208
Location: Salford, UK
|
| Posted: Thu Sep 15, 2011 7:00 am Post subject: |
|
|
| Not that I know of. |
|
| Back to top |
|
|
KennyT
Joined: 02 Aug 2005
Posts: 318
|
| Posted: Thu Sep 15, 2011 8:46 am Post subject: Re: |
|
|
| PaulLaidler wrote: | | 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!  |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
