[fpc-pascal]RE: The inexplicable overflow.

[Pierre Muller]

At 15:28 27/09/2002 , vous avez écrit:
>On Fri, 27 Sep 2002, Pierre Muller wrote:
>
>After significant further searches and hacking the problem still evades 
>me. However, I have since learned that it is apparently not an overflow.
>
>The value certainly does switch to maxint and then to 0 (which is why I 
>thought it was an overflow) but compiling with range checking and overflow 
>checking does not crash the program when it happens. 
>
>In other words, it hits maxint and then 0 but never exceeds maxint. What's 
>even funnier is that it does not build up to maxint, it simple becomes it 
>out of the blue and without warning.
>
>I went so far as to do a text search for the line where.Y throughout all 
>the source code, but I didn't find any lines accessing this value directly 
>except the two which are changed when a character move, and these are just
>inc and dec's. If the problem was here, then surely it could not reach 
>maxint directly - especially as these lines are often not being executed 
>at the time of the bug.
>
>The most perplexing thing remains the fact that only the player seems to 
>suffer this, the enemies (like I said, different instantiations of the 
>same object) are completely untouched.
>
>I will asume by now that nobody here is interested in joining the project 
>(hint, hint) and just hope for some good advice.
>
>Thank you all though, the advice from this list has solved many, many 
>problems for me over a very long time.

There answer to your problem is probably much
easier to find if you use another feature of GDB:
'watchpoints'
A watchpoint in GDB sense (as opposed to the IDE sense)
is an expression that is evaluated and
checked for changes.
This expression can be rather complex and invole checked several memory locations.

In your case, it seems that its simply a globabl variable that suddenly 
gets set to an unexpected value....
This is the best case of use of GDB watchpoints.

So using command line GDB
you should use
(gdb) watch BLOCKY
or from inside the IDE you should use
"Debug|Breakpoint list"
Select "New" button
insert BLOCKY  in name filed and set
type field to watch.

Running the program after setting this watch will 
make gdb stop the program whenever the
value of the watched expression is changed.

If you get too many stops, you could try to add a 
condition (for instance BLOCKY = 0)
so that it only stops when the unexpected value is set.

It might well be that you variable is 
changed by some write operation in a released 
heap fragment that has been reused by the heap manager....

If your expression is not too complex, 
the watchpoint will be a hardware watchpoint,
which means that it works really quickly. 
Otherwise the program gets really slow, because its is 
run instruction by instruction....

Hoping that this will help you to find your problem.