Announcement

Collapse
No announcement yet.

Divide By Zero (RT Error 11) Print Error

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

  • Divide By Zero (RT Error 11) Print Error

    We are using an 850 MHz all-in-one CPU card running in a micro-
    box for a process control application. During troubleshooting it
    was noticed that adding a print statement would cause a very
    repeatable Error 11 (Divide by zero) at runtime. Remove the
    print statement and the error goes away.

    TurboPascal had a bug in its CRT module which resulted in the
    same divide by zero error message. There are several patches
    that can be downloaded from the Internet to fix this bug.

    My question is ... does PowerBASIC have a patch to fix this bug
    in the PowerBASIC/DOS V3.5 library?

    ------------------
    php
    php

  • #2
    To the best of my knowledge, PB is the most bug free compiler on
    the market. There are no known issues with the PRINT (I assume
    to screen) statement. Perhaps if you posted a code snippet, we
    could take a look at it.

    ------------------
    There are no atheists in a fox hole or the morning of a math test.
    If my flag offends you, I'll help you pack.

    Comment


    • #3
      There have been ZERO bugs reported along these lines, whatsoever. That said, if your PB.EXE is dated 19/12/97 then you are using the very latest build (build 19).

      However, from the description I would fully expect the problem to be in the program itself and that program is not using $ERROR ALL ON... hence the real error is quite probably occurring somewhere prior to the PRINT statement.

      Importantly, it is likely that the real cause of the crash might not be a division-by-zero error either... it could just be the symptom of a memory corruption that occurs when code writes beyond the boundary of an array (and overwriting memory being used for other variables, pointers, program code, etc).

      Also, memory corruption can be caused by all kinds of things, including buggy memory managers, poorly written inline-assembler code, misuse of pointers, bugs in 3rd-party apps such as TSR's, etc.

      Basically, compiled code [that does not have all 4 optional error tests active] won't check for errors after every BASIC statement, etc. However, I/O operations (such as PRINT, OPEN, etc) will always check the state of ERR and react accordingly, regardless of the $ERROR metastatement.

      Therefore, when an "unexpected" crash is seen at a PRINT or other I/O statement, you'll know what to do!



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

      Comment


      • #4
        This is sure to get me flamed, but here goes...

        The fastest way to get rid of that error, Phil, is to put a
        $SEGMENT statement in your code.

        ------------------

        Comment


        • #5
          Originally posted by Jerry Mason:
          This is sure to get me flamed, but here goes...

          The fastest way to get rid of that error, Phil, is to put a
          $SEGMENT statement in your code.
          This suggestion is absolutely incorrect. Following this advice is guaranteed to do nothing but waste your time.

          The information supplied by Lance Edmonds is 100.0% accurate and guarantees success.

          Bob Zale
          PowerBASIC Inc.


          ------------------

          Comment


          • #6
            Gentlemen,

            All help is appreciated. I'm sitting at 7,000+ lines of
            PowerBASIC code for our process application and management is
            impressed with the quality of the application so far. It will
            be difficult to offend me because I just picked up BASIC, and
            PowerBASIC in particular, to code this application because we
            wanted an MSDOS-supported compiler environment. Hence, I'm
            still learning all the nuances about PowerBASIC. We resolved
            the problem by removing the troubleshooting print statement but
            Lance's thoughts are undoubtedly correct in that the problem
            does mimic a memory overwrite error. We'll use the
            recommendations from this forum going forward. Thanks again.

            Phil ...

            ------------------
            php
            php

            Comment


            • #7
              Phil--

              Removing the PRINT is not going to help over the longer term. It will simply shift the exception report to another statement later. The important thing is to find the line of code which is actually causing a problem, since the exception may have occured long before the PRINT.

              As Lance mentioned, just add an $ERROR ALL ON and run it again. You likely find the problem in seconds.

              Regards,

              Bob Zale
              PowerBASIC Inc.


              ------------------

              Comment


              • #8
                Bob,

                I will do that today. We are coding the control room touch
                screen interface portion of the application using Delphi and
                Windows so I'm timesharing between the two languages/OSs.
                Your support is appreciated and was one of the reasons that we
                opted to license several copies of PB/DOS V3.5.

                Thanks again,

                Phil ...

                ------------------
                php
                php

                Comment

                Working...
                X