Program crashes outside debugger, runs within debugger

[Cordell Jeppsen]

A more careful inspection of my code resulted in a solution. I had built the dialogs uising PowerBASIC forms. Later I had removed some of the buttons, but some data statements in my code still had references to IDs that didn't exist. Removing those references solved the problem, but I still don't understand why it would work within the debugger but not outside it.

Thanks for everyone's help.

Cordell

[Gösta H. Lovgren-2]

Cordell, try putting some line numbers ( or labels) in your program. See http://www.powerbasic.com/support/pb...ad.php?t=40802 thread for details. There's even a program there that will do it for you without disturbing your current code.

That will help pin down where the error is occurring. Also, as MCM suggested, make sure you have:

#Debug Display On

at the top of your program. It will trap Array Bounds Errors (pretty much the most common "hidden" GPF'ing error in programs).

=============================
"Many a man's reputation
would not know his character
if they met on the street."
Elbert Hubbard (1856-1915)
=============================

[Michael Mattias]

I hope you have #DEBUG ERROR ON in your compiled EXE, since that's the way it runs in the stepping debugger.

Your symptoms sound like an error is occurring but you are not aware of it.. which you might not be if you don't have #DEBUG ERROR ON.

BTW, GPF messages always include a fault error code. If it's 0x00000005 (and it probably is), that does not really help. (Attempt to access unowned memory).

But if it's something else... it could help A LOT.

[Cliff Nichols]

Posting code would help (in more ways than 1, cause maybe we can spot the problem and 2 it could help me with further development of my series of debug handlers)

Faulting that, you could use one of my debug handlers in the source code forum to try to narrow down.
RunTime Debug and Error Handling Part I - Find that elusive bug
RunTime Debug and Error Handling Part II - Find that elusive bug
RunTime Debug and Error Handling Part III - Find that elusive bug

One of them has bound to have something to offer. (Still a work in progress though :shhh

[Walt Thompson]

Hi Cordell;

If possible could you post your code?

This could be a timing issue, the debugger slows your program down somewhat. In your case it slow it enough to allow an operation to complete properly. If it is a timing issue, then the PROFILE statement will point you to the function or sub that is consuming a lot of time.

You may also be able to narrow down the cause of the problem by commenting out functions or sub routines until the the program runs without faulting.

[Cordell Jeppsen]

Thanks. Tried that, but I have the same result.

[Paul Dixon]

Cordell,
if you use any inline assembler in your program (or even if you don't) try adding

#REGISTER NONE

to your program so register variables are not used.
When run in the debugger, register variables are not available to your program so this is a major difference between running in the debugger and not in the debugger.

Paul.

[Cordell Jeppsen]

I have a program I have compiled in PB/Win which works perfectly when run from the debugger. Outside the debugger it fails, with Windows telling me it is sorry but this application had to quit. The application event log gives an address where something faulted, but no other explanation. In the debugger there is no error at all and all features work as they should. Can someone tell me how to go about identifying the problem here?

Cordell