Debugging with #DEBUG ERROR ON

[Alex Chambers]

Hello - I have a stock market application I am using to run tests. In short, the application stores price data in memory in the form of long integer arrays, and mimics buys and sells by moving through these arrays.

I occasionally get a GPF - not always, so it's frustrating to locate. I've been checking array boundaries and these seem to be OK.

Stepping through with the debugger is too slow and impractical. I run roughly 24000 optimisation loops in about 1-2 hours, and the error seems to come half way through these.

I tried using #DEBUG ERROR ON - and the application runs through without GPFing. However, it is not telling me where the problem is!

Is there a way to set some debug code so that instead of GPF, I get "error x at line y ..." or something like that?

Many thanks,
Alex

[Cliff Nichols]

Alex, this may help.
I found in my compiler that there is a "Break-On-Error" option that is not checked by default.

If you do the following in PbWin:

1. Goto Window--->Options...
2. Select the Compiler Tab
3. In the Debugger Options, select the "Break On Error" box

Then in your debugger, you do not have to animate to track down an error. You just have to Follow whatever steps that you follow to "Sometimes GPF", and if there is an error (like an array out of bounds), the debugger will stop at that line.

I am somewhat amazed the option is not enabled by default because isn't that what a debugger is for? To point out errors that you just did not catch while coding?

Anyways, hopefully this time is of use.

[Alex Chambers]

Thanks Cliff - I'll give that a try.

[Alex Chambers]

Sorry - I'm new to PB debugging - and have a question:

After selecting the "Break On Error" box, do I then:

a) Select RUN > Compile and Debug
b) DEBUG > Run (F5)

Will this run my application until I hit the GPF error?

Thanks

[Cliff Nichols]

Alex, if you compile(debug)
and then run, the program will run until you hit an error that the debugger can catch (Like array out of bounds).

It is not foolproof for all GPF's but certainly speeds things up when looking for an error you can not find and can not spend hours "Animating" to find an error.

If you still can not find the error, but know the sequence it takes to cause a GPF, then you will need to roll your sleeves up and start digging into your code that handle whatever the sequence was that caused the error.

It can be a pain, I have code that for weeks I can not find the error, but I know I am getting close. But without the debugger I would still be chasing my tail looking for array out of bounds errors

[Michael Mattias]

Use TRACE instead of stepping debugger. Any errors detected will show up in the trace output. There's a FAQ on this in the FAQ Forum, very nicely explains how to do it.

(Subjective Opinion Follows Alert). Getting one file on which to do a 'find' for "error" beats the snot out of doing it iteractively