Error 51 and error handling problems

[Daniel Corbier]

I previously had difficulty manually inserting error handling
code. This time, I decided to create my own global error
handler by creating a simple program that opens my source
code and automatically inserting On Error Goto ... at the
beginning of each routine, with error handling code at the end
of the routine. It seemed like a solution that would finally
save time in debugging. But this time I got Error #51. The help
file says to contact Tech Support when this error happens.

I started trying to narrow down exact cause of error 51 but I
stopped, because unlike other GPFs that you can just click out
of, this time I was getting hard crashes that froze the whole
computer, and even <ctrl><alt><del> wouldn't respond to.

I was not able to duplicate Error 51 in a short piece of postable
code, but I think I have a general idea what may have triggered
it. It turns out that there was an array that was incorrectly
accessed. However, "On Error GoTo" simply didn't catch it, and
the intricate program just kept on going, until it couldn't any
more and displayed Error 51. Although I don't have concise code
to demonstrate Error 51 I here is something that shows where
"On Error GoTo" fails.

' ------ Beginning of Program
$Compile Exe

Function DoSomething(x As Long, y As Long) As String
   On Error GoTo ErrorHandler
   
   Dim MyArray(x) As Long
   
   MyArray(y) = MyArray(y-1) ' Should catch MyArray(-1)
   
   DoSomething = "There were no errors"
   
   Exit Function
   ErrorHandler:
   DoSomething = "Error #"+Str$(Err)+" in Function: Other"
End Function

Function PbMain As Long
   MsgBox DoSomething(100, 0)
End Function 
'  ------ End of Program

Notice that I am accessing MyArray(-1) -- when the array goes
from 0 to 100. On Error doesn't catch it. In the
actual project, it kept on going until a different location
where that array was redimmed, and then it gave error 51.

Something interesting that I noticed was that "On Error" didn't
seem to work in a DLL, or when I ran it as a regular EXE. However,
when I ran it from the debugger, it worked kind of the way I had
in mind for it to.

But even the debugger didn't trap a GoTo DWORD null correctly.
Thankfully it softly said General Protection Fault in the
debugger and let me gracefully click out of that one. But I
think it should return error #9 for that one as well.


------------------
Daniel Corbier
UCalc Fast Math Parser
http://www.ucalc.com

[Lance Edmonds]

Array subscripts are not bounds checked unless #DEBUG ERROR ON is in effect. The debugger applies an implicit #DEBUG ERROR ON.

Therefore, in your EXE code, accessing an array out of it's bounds would likely trigger a GPF. In these circumstances (without #DEBUG ERROR ON), it is the programmers responsibility to ensure these kind of array accesses are not executed by validating your subscripts. You could think of it as preventative error trapping... please refer to "Errors and Error Trapping" for more information.

Similarly, ON X GOTO expects the value in X to be a valid, and does not range-test X.

If you want to "skip" over the ON GOTO when X=0, then either test explicitly for that value, or change your ON GOTO code slightly. For example:

IF X THEN ON X GOTO Lab1, Lab2, Lab3,...

or maybe:

ON X + 1 GOTO SkipOver, Lab1, Lab2, Lab3,...
SkipOver:
... code here to handle the X=0 case.

So, in summary, your app probably caused a small memory corruption because of the out-of-bounds array access, and the net effect was to trigger an error 51 because the run-time library encountered an unexpected problem.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Daniel Corbier]

You're right . Even before reading this reply, later after
posting this sample I realized that the $Debug Error On
statement in my project was commented out. In the sample I
posted, I didn't use it either. Now that $Debug Error is back
on, my little global error handler works in the DLL the way I
need it to .

For the other item, I meant Call DWORD, but I said GoTo DWORD
(but not On GoTo, which is another type of thing). For
either of those two DWORD pointer operations, I think the
compiler should return error 9 when the target pointer is null.

I am constantly adding, removing, modifying and experimenting
with code at this stage of development (this is usually done in a
temp directory first). Array bound errors and such are eventually
found and dealt with. But a more automatic way of debugging
simply helps me find things sooner rather than later. This way
I have more time to experiment. My new little global handler is
sufficient for now, but a built-in mechanism to do something similar
would be even better.

(Error handling for numeric operations is a different issue. I
don't want to mix the two. Unlike the above error handling which
is handy in the development stage, I still want the option of
adding overflow-type checking in selected functions in finished
products)

------------------
Daniel Corbier
UCalc Fast Math Parser
http://www.ucalc.com

[Lance Edmonds]

Oops, I misread that (ON GOTO vs GOTO DWORD)... sorry!

However, CALL DWORD and GOTO DWORD does not validate the target address either, simply because the runtime engine has no business deciding whether the target address is valid or not - that is up to the programmer.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Daniel Corbier]

Lance, I meant that the Call DWORD address should be checked
when $Debug Error is on. The help file clearly states
that PB/DLL does pointer access checking (and particularly null-
pointer checking). The parameter for Call DWORD is a pointer
according to the help file.

Even if it weren't documented, I think PB should do as much error
checking as possible when $Debug Error is on. One advantage is
that it can save time when debugging. That's the advantage, but
I can't think of a disadvantage?

I think a main problem with the current debugging mechanism is
that it focuses on fast executables, at the expense of quick
development time, or flexibility. These concepts are not
mutually exclusive. Let the programmers decide at what stage of
development they want their executible to be as small and
fast as possible, or when they want heavy error checking.

------------------
Daniel Corbier
UCalc Fast Math Parser
http://www.ucalc.com

[Phil Tippit]

daniel,

try this code for inserting error checking code
http://www.powerbasic.com/support/pb...ad.php?t=23016

phil

------------------
e-mail: [email protected]

[Daniel Corbier]

Phil, I haven't tried your code, but looking through it, it
seems like it would expect the keywords Function and Sub
to be all caps, whereas I use the mixed case option for keywords,
so it wouldn't work as-is for me. And my exported functions have
the word Alias followed by the exported name, before the
parenthesis.

But other than that, it looks like the right idea. Yours is
better than mine, because I haven't added code yet to keep track
of the line number, etc... But so far, the function names alone
have been sufficient for my needs. If I get stuck, I'll probably
add line numbers tracking like yours.

------------------
Daniel Corbier
UCalc Fast Math Parser
http://www.ucalc.com

[Lance Edmonds]

Re: #DEBUG ERROR ON and CALL DWORD, etc... sounds like a good idea... I'll pass this along to R&D for the "wish list".

Thanks!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>