maajs@levels.sait.edu.au (06/01/90)
Turbo Pascal 5.5 and Turbo Debugger Bug.
========================================
The built in debugger with TP5.5, and stand alone TD share a bug.
When evaluating expressions which are displayed in the Watch
window, the evaluation may differ from that made in the code
being debugged.
I made a silly error of using
inside := sqr(x) + sqr(y) <= sqr(r);
to determine if a point was inside a circle, where inside is boolean
and the remaining variables were integer. Naturally, for some values
of x and y, sqr(x) or sqr(y) becomes negative because of overflow
of the 16 bits used to represent integers. If you keep both y and r
fixed (say), and let x increase while printing out the value of
inside, you will see the value change from true (if start out with
x and y inside the circle), to false, and then start to change between
true and false as overflow occurs and sqr(x) becomes negative.
When using the built in debugger, I determined the error was in the code
containing the line above, and was watching the value of Inside. It was
TRUE when I knew it should be false. I also was watching the value of
x*x + y*y <= r*r (you cannot use sqr), and finally (once I had worked
out what was going on), the value of inside=(x*x+y*y<=r*r). The
debugger showed TRUE for Inside, FALSE for x*x+y*y<=r*r, and FALSE for
inside=(x*x+y*y<=r*r). The stand alone debugger shares this `feature'.
Conclusion: TP debugger, and TD do not use a 16 bit representation for
integers when evaluating watched expression. I suspect that the values
are represented with 32 bits, so common code can be used for all integer
types. Don't always trust the values displayed!
I spent a number of hours trying to determine the above error, as I was
playing with some mouse routines I wrote, and the the OO extensions, and
had written some code to enable me to display, in graphics mode, a number
different geometric objecs, grab them with the mouse, and move them about.
As I was testing to see if the mouse cursor was inside an object, cycling
through a linked list of objects, occasionally the wrong object would be
grabbed. There seemed no pattern to the problem. I can see the reasons
why now (as the distance between objects determined if overflow would
occur such that the expression became true when it should not be,
and the order of objects in the linked list determined which circle object
got to `see' the mouse cursor first). However debugging was difficult, and
certainly not helped by wrong information from the debugger. Eventually
I determined the reason by creating a configuration of objects where the
error occured consistently, and following what was happening the the CPU
window. The registers don't lie.
Cheers,
Tony Sobey,
School of Mathematics and Computer Studies,
South Australian Institute of Technology.terra@diku.dk (Morten Welinder) (06/01/90)
maajs@levels.sait.edu.au writes: >Turbo Pascal 5.5 and Turbo Debugger Bug. >======================================== >The built in debugger with TP5.5, and stand alone TD share a bug. >When evaluating expressions which are displayed in the Watch >window, the evaluation may differ from that made in the code >being debugged. > ... >Conclusion: TP debugger, and TD do not use a 16 bit representation for >integers when evaluating watched expression. I suspect that the values >are represented with 32 bits, so common code can be used for all integer >types. Don't always trust the values displayed! Never trust 'em! I have a nasty overwrite problem and I start thinking that the heap management has errors in it . (If anyone out there knows whether this is correct, please let me know). Main point: I'm using the FreeMin variable, and TD acts funny evaluating say "MemAvail", if FreeMin is not zero. I haven't at this time checked using the the internal debugger. >The registers don't lie. Very true! terra@freja.diku.dk (Morten Welinder)