Announcement

Collapse
No announcement yet.

Error 51 and error handling problems

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Error 51 and error handling problems

    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.

    Code:
    ' ------ 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
    Daniel Corbier
    uCalc Fast Math Parser
    uCalc Language Builder
    sigpic

  • #2
    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:
    Code:
    IF X THEN ON X GOTO Lab1, Lab2, Lab3,...
    or maybe:
    Code:
    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>
    Lance
    mailto:[email protected]

    Comment


    • #3
      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
      Daniel Corbier
      uCalc Fast Math Parser
      uCalc Language Builder
      sigpic

      Comment


      • #4
        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>
        Lance
        mailto:[email protected]

        Comment


        • #5
          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
          Daniel Corbier
          uCalc Fast Math Parser
          uCalc Language Builder
          sigpic

          Comment


          • #6
            daniel,

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

            phil

            ------------------
            e-mail: [email protected]
            E-Mail:
            pt AT pursuersoft DOT com

            Comment


            • #7
              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
              Daniel Corbier
              uCalc Fast Math Parser
              uCalc Language Builder
              sigpic

              Comment


              • #8
                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:sup[email protected][email protected]</A>
                Lance
                mailto:[email protected]

                Comment

                Working...
                X