No announcement yet.

PB 3.5 IDE/PBD sync corruption re-visited

  • Filter
  • Time
  • Show
Clear All
new posts

  • PB 3.5 IDE/PBD sync corruption re-visited

    Lance, you or most anyone else should be able to see this as follows.

    I believe I have a recoded simple code example that shows how the
    PowerBASIC 3.5 compiler for DOS comes apart in the IDE debugging mode,
    as well shows the same flaw in the PBD debugger if it is enabled.

    It shows a simple, but by no means fully developed failure, of how this
    entire corruption of the IDE is arising.

    Single stepping this through the attached subroutine will, I think, show
    one all that may be necessary to find and fix what I firmly believe is a
    compiler error in the debugging tools we are to use.

    Mike Luther
    [email protected]


    10 ' TEST1A.BAS * by H. A. M. Luther * Demo IDE corruption * Rev 31-Dec-99
            ' Bear in mind this is in a DOS-VDM in OS/2, but I've evidence
            ' that it is a universal problem with the PB 3.5 IDE and PBD.
            ' Here is a sample program that blows away the PB IDE and PBD
            ' debugger line syncronization.  The use of a COLOR statement
            ' to shift screen colors in text mode which is embedded in a
            ' .PBU, when followed imediately by a PARTIAL printed line of
            ' text, with a trailing semi-colon, then immediately thereafter,
            ' corrupts both the PB 3.5 IDE and the PBD debugger by one
            ' additional line for the instance of such color change added
            ' to MAIN.  As well, corruption following the use of POS(0)
            ' is illustrated.  The errors are capable of compounding,
            ' although that is not illustrated in this sample.
            ' First compile the suggested .PBU as TESTY.PBU
            ' Next, set up to watch the variable BEENHAD% in the watch box.
            ' Then run the below code in the IDE single step mode using the
            ' <F7> key.  Discover that the 'target' line which the debugger
            ' reports as the active line has moved one step upward in the
            ' source from the actual point of execution of the source for
            ' each of these errors!  However, you will find that the damage
            ' isn't as easy to spot as you might think!  For example the
            ' POS(0) error may be tripped *MANY* lines of code downward
            ' into the source!  Finding it can often mean hours of tedious
            ' useless work, expecially where the error compounds with nested
            ' subs using nested error producing routines, are in inter-SUB's.
            ' I believe you will agree you can demonstrate how this compiler
            ' and debugger become corrupt as follows.
            ' Run without *TWO* specific *NUMERIC* line numbers I think you
            ' will find that the IDE/PBD debug operation will slip two lines
            ' upward in this program.  The addition of a single *NUMERIC* line
            ' label in each of *TWO* very specific places will cure this.
            ' Further, if you rewrite the IF-THEN/ELSE statement involved in
            ' the second example of the error differently, I don't think you
            ' can ever cure the fault.  You sometimes specifically must have
            ' the source written exactly the way the compiler seems to optimize
            ' the operational code, in order to syncronize the operation at all,
            ' even with numeric line labels added!
            ' I have seen complex examples in very large programs where this
            ' error not only causes IDE/PBD mis-syncronization, but also is
            ' capable of causing *EXECUTIONAL* errors in the program.  IN
            ' large programs with pre-emptive multi-tasking with complex
            ' nested SUB's, this error is also capable of corrupting the entire
            ' debugging operation such that it leads to total failure of the
            ' system and hard disk destruction in my personal experience.
            ' I think, but so far cannot demonstrate simply, that the reason
            ' for this is that the compiler is missing the line step as a
            ' result of falsely determining, that code to the right of a
            ' semi-colon on in a comment line, is actually executable code!
            ' If a comment is capable of being excuted, has variable names
            ' in the comment common to the program itself, it appears that
            ' comments can become compiled into the program as well!  I think
            ' any reasonable and prudent programmer could thus get in serious
            ' trouble using the product, from the expanded form of this error.
            ' In my humble opinion there is nothing wrong with the way
            ' any of this source is written.  There is no reason anyone
            ' should not be able to change colors in the middle of a
            ' printed line and suffer IDE line display slippage.  There is
            ' no reason anyone should not be able to use POS(0) in the manner
            ' I have illustrated.  Much of the time, the simple setting of
            ' POS(0) to a variable and then using that variable instead
            ' instead inside the complex statement, helps cure this.  At other
            ' times, I suspect depending on how the compiler optimizes, this
            ' is impossible.  This means different programs using a common
            ' form of a library SUB, may indeed, suffer from different jump
            ' errors in the MAIN, depending on how the code compiles!
            ' The functions TIME$ and DATE$, when used directly in an
            ' internal complex nested SUB, also exhibit this same sort of
            ' error in very large programs.  This seems to turn on how
            ' else the error builds before and after such enabled CALLS!
            ' Although this sample does *NOT* display more than two line
            ' slippage for multiple instances of the color shift, larger
            ' programs do.  I have programs more than 20 lines off target
            ' which apparently can be 'fixed' this way, but at the expense
            ' of only dozens of hours work.  That's unacceptable to a user.
            ' This same error, under just the right set of $SEGMENT sizes
            ' in multi-segmented programs, is one of the ones which can
            ' totally destroy an OS/2 DOS-VDM session with SYS3170 unhandled
            ' DosRaiseException errors in my system.  The SYS3170 goes away
            ' the instant the simple equate is added.  If mis-syncronization
            ' occurs next to a segment boundary, it seems the error gets
            ' much worse, very much more difficult to find.
            ' It is an absolute horror to try to trace errors if the suggested
            ' debug point is off-line, as it has been for me in virtually
            ' all my programs since I got the product and before I found this.
            ' I make extensive use of inter-line color changes based on a
            ' standard library with the color change functions.  There is
            ' no reason anyone should not be able to do this.
            ' Even if you know how to fix this, assume that you must do the
            ' below for 100 complex 4000 line MAIN programs, all of which
            ' use an average of 10,000 lines out of libraries, themselves
            ' 'fixed' with numeric line labels.
            ' As well, think what a mess this makes of structured code and
            ' clean readible source.  The added numeric lables have no
            ' real reason to be there and are highly confusing.
            DECLARE SUB PK50500() '                 CLNHLD:
            DECLARE SUB PK50661() '                 BRTWHTBLK:
            DECLARE SUB PK50680() '                 BRTWHTRED:
            $LINK "TESTY.PBU"
            DEFINT A-Z
            PUBLIC GFX%
            BEENHAD% = 0
            CALL PK50661() '                        WHTBLK:
            PRINT "Now is the winter of our discontent."
            ' Set your first Deblug STOP line on the line below
            GOSUB 3000
            ' Now to see the real reason why the COMPILER and IDE come apart
            ' Add a *NUMERIC* line number below such as:
            ' 1320     CALL PK50680() '                   WHTRED:
            CALL PK50680() '                        WHTRED:
            PRINT "We're roasting in all debugging heat!";
            CALL PK50661() '                        WHTBLK:
            PRINT " Phew!"
            PRINT "But baby it's COLD outside!"
            BEENHAD% = 0
            CALL PK50680() '                        WHTRED:
            PRINT "Phew! It's really getting hot in here!";
            CALL PK50661() '                        WHTBLK:
            PRINT " Indeed!"
            IF DMYP$ = "Yes!" THEN
               PRINT " It is!";
               GOTO BKPT1
            END IF '
            ' To see the other place a *NUMERIC* line number has to be added
            ' simply change the line below to:
            ' 1520     PRINT " Indeed it is!";
            PRINT " Indeed it is!";
            CALL PK50500() '                        CLNHLD:
            ' Set your second debug stop line on the line below
            GOSUB 3000
            PRINT "But we still love you PowerBASIC, <CR>: ";
            Z0$ = INPUT$(1)
            ' If you see this as a step line in BLUE before the below, you've
            ' If you see this as a step line in BLUE before the below, you've
            ' If you see this as a step line in BLUE before the below, you've
    3000    BEENHAD% = 1 '                          Once..
            BEENHAD% = 2 '                          Twice..
            BEENHAD% = 3 '                          Three times a gremlin!  [img][/img]
            RETURN '                                But we still love you!

    Below is the code TESTZ.BAS you will need to create the .PBU required


             $CODE SEG "TESTY"
             $COMPILE UNIT "TESTY.PBU"
             DECLARE SUB PK50500() '                 CLNHLD:
             DECLARE SUB PK50661() '                 BRTWHTBLK:
             DECLARE SUB PK50680() '                 BRTWHTRED:
             DEFINT A-Z
    SUB PK50500() PUBLIC '                          CLNHLD:
             LOCATE 11, 5
             DMGY$ = STRING$(80 - POS(0), " ") '    Make blank string / length
             PRINT " Woof!  You've been bitten by a puppy!";
    50500    END SUB
    SUB PK50661() PUBLIC '                          WHTBLK:
             ' Globals are GFX%
                IF GFX% = 3 OR GFX% = 4 THEN
                   COLOR 7, 0
                   COLOR 15, 0
                END IF
             END SUB
    SUB PK50680() PUBLIC '                          WHTRED:
             ' Globals are GFX%
                IF GFX% = 1 OR GFX% = 3 THEN
                   COLOR 7, 0
                ELSEIF GFX% = 4 THEN
                   COLOR 7, 4
                   COLOR 15, 4
                END IF
             END SUB
    ' *****************

    Happy new year.

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

  • #2
    Interesting Mike, and thanks for getting the example together. I'll be forwarding them on to R&D for their analysis as promised.


    PowerBASIC Support
    ( mailto:[email protected][email protected]</A> )
    mailto:[email protected]