Announcement

Collapse
No announcement yet.

Error compiling with PB but not with PBC

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

  • Error compiling with PB but not with PBC

    I have a PB/DOS 3.5 program that runs fine if the main file is compiled with PBC.EXE, and returns a runtime error 9 at 6969 (which seems me not due) if the main file is compiled within PB.EXE (and executed outside the IDE).
    Trying to isolate a piece of code to post, the problem goes away. So unfortunately i can' t post a compilable example.
    I attach some piece of code just in case to give an idea, however it' s just a general question: is there actually any known reasons for a difference between compiling with PBC and PB, even if restricted to errors detection.

    Thanks.


    -------- Details ---------

    The input data, the PC and OS (W95 4.00.950B) are the same.

    The program has several PBUs and $INCLUDE.

    The problem started when i added this FUNCTION to a unit.


    DECLARE FUNCTION FUNBaseDec(BYVAL Prezzo AS DOUBLE) AS DOUBLE

    ' ======>
    FUNCTION FUNBaseDec(BYVAL Prezzo AS DOUBLE) AS DOUBLE

    DIM Decimali AS LOCAL DOUBLE, N AS LOCAL INTEGER

    IF BaseDecPrezziVideoBD_g > 0 THEN

    N = 100 ' : 2 decimali.

    IF BaseDecPrezziVideoBD_g < N THEN

    ' : La base (es. 32 per il Bond) è coerente con il num. di cifre dec.
    ' autorizzate.

    ' ------> Estrae 2 (se N = 100) cifre decimali.

    Decimali = INT(Prezzo * N) / N ' : XXXXX.xx

    Decimali = Decimali - INT(Decimali)' : 0.xx

    Decimali = Decimali * N ' : xx

    ' <------

    ' ------> Trasforma i decimali da 100esimi a BaseDecPrezziVideoBD_g-esimi.

    Decimali = Decimali * (BaseDecPrezziVideoBD_g / N) ' : xx

    ' <------

    FUNBaseDec = INT(Prezzo) + Decimali / N ' : XXXXX.xx

    ELSE
    PRINT: PRINT "!!!!! ERRORE 882 ! FUNBaseDec: BaseDecPrezziVideoBD_g="; BaseDecPrezziVideoBD_g; "N="; N; " -- COMUNICARLO !!"
    BEEP: BEEP: BEEP
    END

    END IF

    ELSE

    FUNBaseDec = Prezzo

    END IF

    END FUNCTION
    ' <======

    If i REM all these statements, recompile all the units with PBC and the main module with PB, the error doesn' t occurr. If i unREM these statements and recompile all the same way, the error occurrs.

    So, with PB the error occurrs only if these statements are active, and with PBC the error never occurrs, not even with these lines active.

    However the runtime error 9 doesn' t occurr in this function, but on the line

    IntestCMX_s$(1, 7) = zTAB$+"TSU"

    Looking at the code, this statement is near to the top of main module and should only be executed once, at program startup, much before the moment the runtime error occurrs.

    I think this array doesn' t matter, anyway it' s previously declared with

    DIM DYNAMIC FmtCMX_s(1 TO 2, 1 TO 7) AS STRING, IntestCMX_s(1 TO 2, 1 TO 7) AS STRING
    PUBLIC FmtCMX_s$(MIN, 2), IntestCMX_s$(MIN, 2)


    PBC.EXE and PB.EXE are 18 Dec 97 3.50.

    Each unit and the main module have these lines.

    -----------
    $DIM ALL
    $DYNAMIC
    $CPU 80386

    $ERROR ALL ON

    $FLOAT NPX
    $OPTIMIZE SPEED
    $OPTION CNTLBREAK OFF
    $OPTION GOSUB OFF
    $STACK 8192
    $LIB IPRINT ON
    $LIB COM OFF

    DEFINT A-Z: OPTION BASE 1
    -----------

    PBC is run with the options /OP /OU.

    The compilation options of the IDE are:

    =================¦ Compiler
    ----------------------------------
    Code generation 8086/8088
    Floating point Emulation
    Variable declarations None
    Optimize Faster
    Gosub preserve if error Off
    Map file generation Off
    Pathnames in unit debug On
    Unit: full debug info On
    Attach PBD debug info Off
    Error tests
    +--------------------+------------
    ¦ Stack test Off ¦
    ¦ Bounds test Off ¦
    ¦ Overflow test Off ¦
    ¦ Numeric test Off ¦

    ==¦ Linker ¦
    --------------------------
    Serial communications On
    Printer On
    Control-Break (EXE) On
    Full float emulation Off
    Interpreted print Off
    Graphics On
    Video cards
    +----------+--------------
    ¦ CGA On ¦
    ¦ EGA On ¦
    ¦ VGA On ¦

  • #2
    Email the code and all necessary data files to Tech Support and we'll look into your problem and see if we can spot the problem.

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

    Comment


    • #3
      I ran into that problem a couple of times myself.

      Fixed it by using a couple of $SEGMENT metatstatements.

      Seems PB will compile but might get squirelly when it gets near a segment boundary.

      Just checking.. you DID validate that your subscript was in range after you got the error #9, didn't you?

      MCM

      Editing 11/28: I just noticed, you have $ERROR BOUNDS OFF in your PBC compile. That will disable the error 9!!

      Recompile with $ERROR ALL ON and you'll probably get the error.

      Then use the Compile/FindError to locate the source code line where the error occurs.


      ------------------
      Michael Mattias
      Racine WI USA
      [email protected]

      [This message has been edited by Michael Mattias (edited November 29, 2000).]
      Michael Mattias
      Tal Systems Inc. (retired)
      Racine WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        About validating that my subscript was in range when the error occurrs, here is how i ...decided that it was. I hope i didn' t made a mistake.

        - The array was dimensioned with

        DIM DYNAMIC FmtCMX_s(1 TO 2, 1 TO 7) AS STRING, IntestCMX_s(1 TO 2, 1 TO 7) AS STRING

        and the error is on a reference to element (1, 7) of IntestCMX_s:

        IntestCMX_s$(1, 7) = zTAB$+"TSU"

        Two statements before the error, there is a reference to element (1, 6), which gives no error: IntestCMX_s$(1, 6) = zTAB$+"MMM".
        The array is dimensioned only once, with the above DIM, so actually i can' t see any reason for (1,6) to work and (1,7) not to.
        It seems me that the error is not related to array dimensioning. However, i don' t feel very comfortable with the statement i used to share the array with one unit:

        PUBLIC FmtCMX_s$(MIN, 2), IntestCMX_s$(MIN, 2)

        But according to the manuals it seems me to be correct.

        - The error is reported to be on a line which is in the main module header (initialization), far before the beginning of the 1st user loop. But when the error occurrs, the program execution is definitely inside that loop (and many others).

        - If i compile the main module with PBC instead of the IDE, that error disappears.
        So, if my subscript was out of range, the runtime error would be right and due, but we would be now talking about the why a due runtime error is triggered by PB and not by PBC.

        - If i REM the previously mentioned FUNCTION in the unit, PB and PBC both compiles to an exe which runs fine.

        Michael,
        <<
        "I ran into that problem a couple of times myself. Fixed it by using a couple of $SEGMENT metatstatements."
        >>
        Do you "just" fixed some of these UFO errors, or using $SEGMENT helped with differences between PB and PBC?

        Comment


        • #5
          Michael, i just read your re-edited note, but i' m not understanding.

          <<
          "I just noticed, you have $ERROR BOUNDS OFF in your PBC compile."
          >>
          I' m not sure if you mean the screenshot i had included in my post:

          Error tests
          +--------------------+------------
          ¦ Stack test Off ¦
          ¦ Bounds test Off ¦
          ¦ Overflow test Off ¦
          ¦ Numeric test Off ¦

          Anyway, i have $ERROR ALL ON in each unit and in the main module. This should override the settings made from the IDE and from command line options. I really hope not to be wrong on this...

          <<
          "Recompile with $ERROR ALL ON and you'll probably get the error."
          >>
          No, i' m actually compiling everything with $ERROR ALL ON, and if i do it with PBC, no errors.

          Comment


          • #6
            And Mike ...


            Seems PB will compile but might get squirelly when it gets near a segment boundary.
            Those who run into this also need to know that when you run into
            this, and you do break MAIN up into pieces, you'll often run into
            all kinds of wierd things that can be fixed even after you use the
            $SEGMENT technique! I find there is something specifically around
            the 45K segment size boundary that evokes this, but I cannot isolate
            it at all. If you add or take away a line or so of code either side
            of the boundary - the error(s) simply vanish.

            You'll 'fix' the problem with $SEGMENT. You'll go for a long time
            and never see anything. Then all of a sudden the code will come
            apart again! All it will take is to move the $SEGMENT statement
            a few lines either way and the corruption simply vanishes.

            I've tried pointering things, everything I can think of in these
            large programs to isolate it. I cannot. And I have furnished code
            that demonstrates it which hasn't apparently been of use finding it,
            either.

            I don't pose to be any expert at all at any of this. As best I can
            purely guess, in that variable corruption in and around CALL's is
            seemingly related as well, I wonder if it is all related to byte
            mis-alignment on segment boundaries?

            The simplest thing to do seems to be just use $SEGMENT, together
            with MEMPACK, even though MAIN isn't at 64K, but at 45K, and just
            go about life and forget the whole thing. Just be prepared to
            shift the location of $SEGMENT up or down and go on about life.
            Odd this should be posted right now. I've got a MAIN in development
            right now at 82K split into 45K and 37K, based on a quite reasonable
            best guess at what will eventually be yet another PBU. I've moved
            the $SEGMENT boundary two times now in four days just to cure
            this same sort of stuff. It's trivial now that I know what to do
            when it happens, but until I figured out the ring-around-the-rosy,
            it was frustrating.





            ------------------
            Mike Luther
            [email protected]
            Mike Luther
            [email protected]

            Comment


            • #7
              At this time, Tech Support has received Davide's code but not yet had time to analyse it.

              However, since several people are keen on posting anecodal evidence without sending or posting compilable code to prove their claims, we must fairly and reasonably point out that these types of problems are most often due to memory corruption and the causes can be wide an varied, and are usually not in the section of code that shows up a problem.

              Common examples are O/S memory manager issues (bugs!), the misuse of pointers, bad inline assembly, etc. These types of problems are not often caught by $ERROR ALL ON since they are not usually "errors" per se, but it certainly helps to add that meta-statement to help catch "simple" bounds errors, null-pointers, etc.

              Of course, if you use ON ERROR RESUME NEXT in your code and fail to test for error conditions, you'll do yourself an injustice too, as you'll simply "miss" the error condition when it occurs.

              So, at this point in time, if anyone has code that points to a possible or suspected bug in the compiler - then PLEASE submit it to Tech Support... unless we can duplicate/confirm a problem of this nature, we can't fix it.

              On this basis, posting unproven/anecdotal stories helps no one and can cause unnecessary time loss chasing red-herrings. What concerns me is that PowerBASIC have pointed these facts out to certain BBS members before, and yet example code to back up these (as yet) unproven claims remains sight-unseen.

              In fairness, I should mention that we have received code that concerns minor issues (unrelated to this thread) and for that we are grateful.

              We thank you for your cooperation on this matter, and we will post the results of out analysis of Davide's code when the analysis is complete.


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

              Comment


              • #8
                Just for the heck of it, what happens if you go to zero-based arrays?
                Code:
                DIM thearrays(0 to whatever, 0 to whatever) AS whatever
                PUBLIC thearrays(MAX,2)
                Sure, you waste 2 bytes per array per dimension (the "0" elements), but you get more efficiency and maybe in this case, working code.

                MCM


                Michael Mattias
                Tal Systems Inc. (retired)
                Racine WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  <<
                  Just for the heck of it, what happens if you go to zero-based arrays?
                  DIM thearrays(0 to whatever, 0 to whatever) AS whatever
                  PUBLIC thearrays(MAX,2)
                  >>

                  Further to your suggestion i tried:

                  DIM DYNAMIC FmtCMX_s(1 TO 2, 1 TO 7) AS STRING, IntestCMX_s(0 TO 2, 0 TO 7) AS STRING
                  PUBLIC FmtCMX_s$(MIN, 2), IntestCMX_s$(MAX, 2)

                  The error 9 turned into Error 208 at pgm-ctr: 6992 (invalid string handle).
                  It is the next line: FmtCMX_s$(1, 7) = zTAB$+"\ \"
                  The docs says that this is similar to error 242: String space corrupt.
                  The same if i keep using MIN but use "0 TO" instead of "1 TO".

                  I' m sure i went near some boundaries of something somewhere more and more during development, without being aware of it due to my insufficient knowledge of these aspects.
                  Now i got too near, i went over.
                  The only thing i know i have to do about these problems, is keeping each compiled code segment under 60K, but i' m sure that with more experience and knowledge about these things, i would have followed development guidelines that would have not even made me fall into this. BTW, the only loss is that i can' t debug with PBD anymore, which is very useful. I ever can get running EXEs.

                  Comment


                  • #10
                    242 String space corrupt? That could be an offshoot of an error 9 (array bound violation).

                    Or, you could have a SUB/FUNCTION in an external module with a DECLARE whcih does not match the procedure and the stack is corrupt;or, you could have insufiicient stack (this is not likely).

                    The first situation I describe is this

                    Code:
                    ' UNIT.BAS
                     FUNCTION MyFunc (A AS INTEGER, B AS INTEGER) AS INTEGER PUBLIC
                     ' cool code  
                     END FUNCTION
                    
                    ' File: MAIN.BAS
                    DECLARE FUNCTION MyFUNC (A AS LONG, B AS INTEGER) AS INTEGER
                    $LINK "UNIT.PBU"
                        X = MyFunc (arguments)
                        ...

                    I suggest you re-check your procedure headers, and if you do not use explicit typing (either with AS or a type specifier)check any DEFxxx statements you have in use.

                    Regardless, if you use PBC with the RE option (find run-time error); you should
                    be able to then insert the correct debug code to write values to the screen or to disk.

                    One last thought.....
                    If you compile the UNITs without ERROR ALL ON and fail to have an ON ERROR GOTO in the unit code, errors in the unit code can reflect themselves as "mystery" errors when you return to the main module.
                    So you might want to recompile your units and make sure they have ERROR ALL ON.

                    MCM


                    Michael Mattias
                    Tal Systems Inc. (retired)
                    Racine WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment


                    • #11
                      Apologies to Lance, but I can't count the number of times that
                      I've added or moved $SEGMENT directives by a few lines just to
                      get working code.

                      And even if Mike Luther's analysis is wrong, his technique does work,
                      and deserves to be heard so others can benefit from it.




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

                      Comment


                      • #12
                        Checking the procedures headers is a thing that i actually can' t do, so i' ll do it later, however it seems a good idea, thanks.

                        I also checked the situation you described, but it should not compile, and it doesn' t. Probably, PB detects that the parameter is mismatched. It gives a compilation error:
                        Error 481: Parameter mismatch - may need ByCopy: MYFUNC

                        This is the code i tried:

                        --------------------
                        ' File: MAIN.BAS

                        $COMPILE EXE

                        $ERROR ALL ON

                        DECLARE FUNCTION MyFUNC (A AS LONG, B AS INTEGER) AS INTEGER

                        $LINK "UNIT.PBU"

                        PRINT MyFunc (1, 2)

                        END
                        --------------------
                        --------------------
                        ' File: UNIT.BAS

                        $COMPILE UNIT "UNIT.PBU"

                        $ERROR ALL ON

                        FUNCTION MyFunc (A AS INTEGER, B AS INTEGER) PUBLIC AS INTEGER

                        MyFunc = A + B

                        END FUNCTION

                        END
                        --------------------

                        About using PBC with /RE, i get the same information i was getting with Find Error within the IDE.

                        <<
                        So you might want to recompile your units and make sure they have ERROR ALL ON.
                        >>
                        Really, i do have $ERROR ALL ON in each unit and in the main module.

                        Comment


                        • #13
                          Hi Davide,
                          I was having some problems with some string arrays and I think
                          adding $Dynamic fixed it. Something to try anyway. Good Luck!!

                          ------------------
                          [email protected]

                          Comment


                          • #14
                            Mike ..

                            I hate to be a pest and .. what you said is correct and yet:

                            One last thought.....

                            If you compile the UNITs without ERROR ALL ON and fail to have an ON ERROR GOTO in the
                            unit code, errors in the unit code can reflect themselves as "mystery" errors when you
                            return to the main module.

                            So you might want to recompile your units and make sure they have ERROR ALL ON.
                            On page 24 of the manual, it explicitly states:

                            The error tests specified with this metastatement override the default
                            (ALL ON) ...
                            Further, since it specifically notes that the $ERROR metastatement should
                            only be used once ... in any module before any executable code, one
                            would, I hope, be able to conclude that the default state for all this
                            stuff is the ALL. You shouldn't have to do anything to have the services
                            of the error trapping for all of them in any UNIT you make.

                            Or is this garbled in the documentation? If I don't set it otherwise,
                            which I never have, and in the IDE compile window, they are all still
                            showing "ON" which I think is the default, why does anyone have to
                            hand include this in the header code to get the service?

                            Curious George here...

                            ------------------
                            Mike Luther
                            [email protected]
                            Mike Luther
                            [email protected]

                            Comment


                            • #15
                              The situation I was thinking of is the need for ON ERROR GOTO in the called module.

                              I have not worked much with PB/DOS for about a year, so my memory is hazy, but it seems I recall something about needing ON ERROR GOTO in the unit or you don't get the line-by-line checking that generates.

                              I am thinking this...

                              Code:
                              ' UNIT.BAS
                                FUNCTION Foo (X AS LONG) PUBLIC  AS INTEGER
                                 [really cool code goes here]
                                END FUNCTION
                              
                              'UNIT EUNIT.BAS
                              
                                FUNCTION Foo (X AS LONG) PUBLIC  AS INTEGER
                                 ON LOCAL ERROR GOTO somewhere
                                 [really cool code goes here]
                                END FUNCTION
                              ...that these two units compile differently. The second unit will immediately respond to a current "ON ERROR GOTO" trap in the calling module, but the first module won't.

                              Of course, I have been working with so many different compilers lately I'm not sure which way is up.

                              MCM

                              Michael Mattias
                              Tal Systems Inc. (retired)
                              Racine WI USA
                              [email protected]
                              http://www.talsystems.com

                              Comment


                              • #16
                                The problem, for the moment, is solved by un-sharing the array IntestCMX_s$() the error occurred on. Instead of making it PUBLIC, it' s passed as a parameter to the procedures that need it. No errors occurr anymore (but the mines..).

                                I did put ON ERROR GOTO 0 in all the code modules (none had it, just some ON LOCAL ERROR). I still get an error 9 but at a different location, still on a 2D string array which is PUBLIC like the previous one, but this is in another unit.

                                Comment

                                Working...
                                X