No announcement yet.

PB 3.5 compiler weirdness woes.

  • Filter
  • Time
  • Show
Clear All
new posts

  • PB 3.5 compiler weirdness woes.

    I have a large application, 18000+ lines long. I've been
    fighting problems that I can not understand. It seems that
    when I move code around, or place a $SEGMENT compiler directive
    in a different place, the weirdness will disappear, at least
    for a while. I thought all of this was behind me and I could
    make code changes at will, without worrying about weird problems.
    But now, I have another problem occuring. I'd like to
    understand this.

    If I add 3 new variables to my large global declarations file,
    called "globals.bas", my application crashes before even getting
    started (with an error 5 at 393215). It won't even print the
    first print at the beginning of the program.

    If I comment out these 3 new variables, the program runs.

    If I put these 3 new variables in a new file called
    "globals2.bas", and $INCLUDE this after the $INCLUDE for
    "globals.bas", it crashes.

    Now this is what's really weird. If I comment out these 3 new
    variables, so that "globals2.bas" is essentially 3 comment lines,
    The program will crash as well.

    And if I comment out the $INCLUDE "globals2.bas", the program
    will run.

    The executable file size (call it "Executable A")
    when compiling with
    $INCLUDE "globals2.bas"
    (which is filled with three comment lines) is the same as when
    I compile (call this "Executable B") with
    '$INCLUDE "globals2.bas"

    This is to be expected. The actual compiled statements are the
    same. Yet the compiler code which is output is different.
    Executable A crashes, and Executable B runs.

    When looking at differences between the two executable files,
    with a binary file difference analyzer, there are NUMEROUS

    If I try to use the compiler to find address 393215, it can not
    find it. Interestingly enough, 393215 in hex is 5FFFF.

    I have assumed that I must be executing code inadvertently in one
    of my numerous $INCLUDE statements, so I have tried putting a
    print "start" between $INCLUDE sections to see if my code at
    least gets there, since my print statement at where I THINK
    is the beginning of my code does not execute. The print
    statement between $INCLUDEs does indeed print before giving
    me the error 5. But again, here is some weirdness.

    If I put the print after the last include before one particular
    $SEGMENT, I get the "start" message, then error 5. If I put
    the print after the $SEGMENT statement, Windows tells me I've
    executed an illegal instruction and terminates the application.
    If I put the print after the next $INCLUDE in the next
    $SEGEMENT, the program will run! Since when should a properly
    placed PRINT statement fix the ability of an application to run?

    Can ANYONE provide me with insight as to what I may be doing
    wrong to cause such weirdness? I am baffled. I can not
    apply traditional debugging techniques to these problems.

    Thanks in advance.



  • #2
    What are the sizes for the segments?
    Do you compile with $Error all on?

    Kind regards,



    • #3
      James ..

      You'll find my Email address below. If you like, you can reply to it
      and get a path started. I guarantee you are not alone from the replies
      to all this which are here inbound to it and from substantial discussion
      going back years here on at least some of what you post.

      I'd like to see the replies here from others before I post anything
      here in open reply. Just because I think that things are relevant based
      on what I can see here doesn't mean they are so. If there's been anything
      more found by someone else important, it's better to see what is offered
      here to from other posts are before anything else I post here.

      Looking on what is posted by others here, I'll offer you what all that
      seems important here over all this.. But let's get others to talk up
      before here, OK?

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


      • #4
        Here are the segments for a version that doesn't run, with
        the GLOBALS2.BAS $INCLUDEd after GLOBALS.BAS - The 3 variables
        are NOT commented out at this time.

        Start Stop Length Name

        00000H 00000H 00000H LSEG1
        00000H 0809FH 080A0H LSEG2
        080A0H 0863FH 005A0H LSEG3
        08640H 086BFH 00080H LSEG4
        086C0H 087DFH 00120H PowerBasicSeg01
        087E0H 088FFH 00120H PowerBasicSeg02
        08900H 08D5FH 00460H PowerBasicSeg03
        08D60H 1464FH 0B8F0H PowerBasicSeg04
        14650H 2197FH 0D330H PowerBasicSeg05
        21980H 2D03FH 0B6C0H PowerBasicSeg06
        2D040H 3A27FH 0D240H PowerBasicSeg07
        3A280H 3C72FH 024B0H PowerBasicSeg08
        3C730H 3CE4FH 00720H PCL_DATA
        3CE50H 3DECFH 01080H PCL_TEXT
        3DED0H 3DEDFH 00010H _TEXT
        3DEE0H 3DEEFH 00010H _DATA
        3DEF0H 4BE7FH 0DF90H LBSVGA1
        4BE80H 4C53FH 006C0H LBSVGA
        4C540H 526DFH 061A0H LBSVGA2
        526E0H 526E0H 00000H VSEG
        526E0H 526EFH 00010H RSEG
        526F0H 54B4FH 02460H SSEG
        54B50H 6244FH 0D900H DATA

        When I place GLOBALS.BAS in the following place, with
        variable declarations uncommented, it works fine. Here's
        my declarations in the order that work.
        $ERROR ALL OFF

        $LIB ALL OFF
        $DIM ALL
        $EVENT ON
        $STACK 14000

        $include "c:\source\pb35\svgaprog\include\SVGAPB.BI"
        $link "c:\source\pb35\svgaprog\lib_pb35\SVGAPB.PBL"

        $INCLUDE "PCL4PB.BI"
        $LINK "PCL4PB2.OBJ" 'Interrupt driven serial port I/O

        $INCLUDE "GLOBALS.BAS" 'Global Variables DIM Statements
        $INCLUDE "SCR_DIMS.BAS" 'Screen variables DIM statements automatically
        $INCLUDE "DBG_DIMS.BAS" ' Debugging Dim Statements
        ' generated by Visual Basic form
        $INCLUDE "SCR_VARS.BAS" 'Screen definition variables automatically
        ' generated by Visual Basic form.
        $INCLUDE "DBG_VARS.BAS" ' Debugging Variables
        $INCLUDE "SCRNCLRS.BAS" 'Sets all the Screen Object's Colors
        $INCLUDE "DBG_CLRS.BAS" 'Sets all the debug screen object's colors

        $EVENT OFF
        $INCLUDE "XMEM.BAS" 'Handles XMS Functions
        $INCLUDE "PCXPAL.BAS" '.PCX file handler and palette functions
        $EVENT ON
        $INCLUDE "CORRECTI.BAS" 'Routines for applying correction factor
        ' and maps to raw data
        $INCLUDE "SCREEN.BAS" 'Screen Handler functions for labels,
        ' pictureboxes, etc.
        $INCLUDE "PC104PSWD.BAS" ' Verifies Password to enter PC104 Command Line
        $EVENT OFF ' Make sure UEVENT doesn't try to run when performing DIO
        ' as the Uevent routine uses DIO functions as well, and might
        ' get triggered in the middle of one of these routines,
        ' causing the result to be incorrect.

        $INCLUDE "QUEUE.BAS" 'Handles queueing of scan trigger positions
        $INCLUDE "DIO.BAS" 'Digital I/O code
        $EVENT ON
        $INCLUDE "STATS.BAS" 'Computes the statistics for scans/event/roll
        $INCLUDE "PC7266.BAS" 'Code which deals with the PC7266 encoder board
        $EVENT OFF
        $INCLUDE "ISR.BAS" 'Interrupt Service Routines for triggering
        'print "Start"
        $EVENT ON
        $INCLUDE "INIT.BAS" 'Initialized variables to known states
        $INCLUDE "MAINFUNC.BAS" 'Main User interface functions.
        $INCLUDE "PC104CMD.BAS" 'Processes keystrokes for PC104 Command line prompt.
        $INCLUDE "KEYPRESS.BAS" 'Processes keystrokes for various screens
        $INCLUDE "DUMMY.BAS" 'Produces Dummy data to store as scans (for testing)
        $INCLUDE "GLOBALS2.BAS" ' This is a test here.
        $INCLUDE "DISKIO.BAS" 'Anything Disk related--reading in data from
        ' Excel .csv file, reading playback data from
        $INCLUDE "DISKIO2.BAS" 'Anything Disk related--reading in data from
        $INCLUDE "UEVENT.BAS" 'UEvent code which executes 18.2 times per second
        $INCLUDE "PROCESS.BAS" 'Processes scan data that has come in.
        $INCLUDE "DEBUG.BAS" 'Shows Debug information, and also Scanner states
        ' on the bottom of all screens
        $INCLUDE "PROALARM.BAS" 'Profile Alarm code.

        The Segment locations and lengths are all the same as before.
        (I double checked this)

        I can not normally run with $ERROR ALL ON because of the size
        of the program (as I have to shell out to the command prompt to
        do DOS commands, and I have network drivers loaded as well to
        transfer data collected from the app to a networked drive).
        But I did compile it with $ERROR ALL ON to see what it would
        complain on for this version that doesn't run, since it doesn't
        seem to get very far at all before erroring out. Here's what
        I got this time.

        Error 244 at pgm-ctr: 335473
        244 is Missing library
        You excluded a library in the library stripping menu and you used
        a function in your program that is contained in that library.

        This address corresponds to this line:
        lbl_DecimetersPerRevolution.Caption = USING$("#.###",DecimetersPerRevolution(%T1))

        This isn't informative either, as when the program does start
        up correctly, this statement executes just fine.

        For now, I am simply $INCLUDE(ing) the new variables where they
        are show in the code above, so I can continue. But it still
        really bothers me that I am having to deal with these problems.

        Any more ideas?

        Thanks. I know this is a screwy/tough one.



        • #5
          We're not going to get far wandering around in the dark. If you could
          submit the code to tech support, we will have a chance to offer more
          useful advice. mailto:[email protected][email protected]</A>

          I see that the program appears to have hardware interrupt service
          routines-- an easy way to get to the fabled Land of Weird Errors.
          Do make sure that you have only asm code, not PB code, in the
          interrupt handlers. The PowerBASIC runtime routines are not reentrant.

          Tom Hanlin
          PowerBASIC Staff


          • #6
            I've run across this problem once or twice. The problem is that
            some of your segments are right on the ragged edge of being too
            big for a segment. All that it takes to push it over the edge
            is, in your case, adding one or two statements and the compile
            goes south.

            I solved this problem by removing every $SEGMENT statement in
            the source code (starting with a clean sheet, so to speak) then
            try compiling the program. When it reaches the EXCEEDS 64K (or
            something like that) error message, just add in a $SEGMENT
            statement at an earlier, appropriate, entry point.

            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.


            • #7

              If I put these 3 new variables in a new file called
              "globals2.bas", and $INCLUDE this after the $INCLUDE for
              "globals.bas", it crashes.

              Now this is what's really weird. If I comment out these 3 new
              variables, so that "globals2.bas" is essentially 3 comment lines,
              The program will crash as well.

              That seems correct to me. I always thought that commented lines
              were included in on the size, I could be wrong. If I am, somebody
              will correct me.



              • #8
                It appears that rebooting Windows 98 may have possibly solved
                this issue. I can not recreate the problem today with the same
                code I zipped and sent to Lance. I just tried it. I HAVE added
                a little bit of software to Windows, but that should not have altered how a
                DOS window's environment behaves.

                It would be nice if this is the "fix". It appeared to be a
                compiler problem because shuffling things around would make
                things work again/behave differently, but the real problem
                seems to lie in Windows 98. I'll continue to do development
                work in Win98 in hopes of finding another ill-compiled program
                combination, then reboot to test my hypothesis and let
                everyone know.

                I rebooted to DOS on Friday when I had these problems and the
                code compiled sucessfully and ran, so I've been developing
                in DOS only since then. I just recently tried to recreate the
                problem again by compiling under a Win98 DOS prompt with the
                zipped file I sent, and can not.

                Have I stumbled onto something? Has any users who have had
                these problem ever experienced it in pure DOS (not a DOS window)?
                If so, would rebooting not let you recompile sucessfully? Did
                you try it?

                I can recall one time when I had these problems. I was
                screwing around for hours without luck of getting any code
                combination to run. When I did get the code to run, I tried
                "breaking" it, and found I couldn't anymore. I couldn't
                explain it at the time, but perhaps I rebooted???