Mail Archives: djgpp/2000/04/18/17:19:57
Hans-Bernhard Broeker wrote:
>
> J.P. Morris <doug-15 AT bigfoot DOT com> wrote:
> > Eli Zaretskii wrote:
>
> >> I suggest using the _CRT0_FLAG_FILL_SBRK_MEMORY (not
> >> _CRT0_FLAG_FILL_DEADBEEF!) to see whether this is your problem.
> >>
>
> > At one stage I tried this, but it crashed by NULL dereference
> > instead.
>
> You should have tried that in a debugger, and checked where this NULL
> pointer came from, to find the bug.
Assuming I can get it to compile so that it will work inside the
debugger, what then? I've only ever used debuggers with faults
that occur every time, not intermittent ones. Stepping through the
code will not be practical due to the sheer volume of code run each
cycle of the game loop, most of which takes place inside a VM.
Since I will only know the bug has occurred when it has already happened,
how can I trace this kind of bug?
Also, there are a few other phenomena I forgot to mention.
The problems occur with a particular data type, called 'object', which
is a structure. All objects are allocated through a particular function,
and to speed up garbage collection, I maintain a linked-list of all valid
object pointers. By looking to see if an object's address is in the master
list, I can detect invalid objects before they are dereferenced.
The problem is, sometimes the objects go bad just after' I've checked them:
e.g.
CHECK_OBJECT(object); // This bombs out if object pointer is invalid
move_object(object,10,10);
Now, the worst thing is that quite often, the pointer passes the
CHECK_OBJECT() test OK, but when it reaches move_object(), it has
turned into 0x203206 or something.
Does this suggest anything?
Also, I have just found, the program works without crashing in a DOS box,
but crashes in pure DOS. None of the classic causes in the FAQ seem to
be the problem, unless I'm missing something.
>
> > Fortify (and presumably MSS et al) put sentry-blocks around memory that
> > is allocated dynamically, using a wrapper around malloc() and calloc(),
> > but since malloc and free aren't used for local arrays or other objects,
> > it wouldn't detect that unless it was a big enough overrun to reach
> > a dynamically-allocated object.
>
> Right. To detect overruns or underruns in arrays not coming from
> malloc() (i.e. automatic ones on the stack, or static ones), you need
> other tools. You might want to try the GCC extension 'Checker-gcc',
> for this. Unlike the usual malloc()-checkers, it can also check
> non-malloc()ed storage. It will only work with Linux, not DJGPP,
> though.
I'll try that. If there is a problem like this it should find it
even if the game doesn't crash in linux.
> --
> Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
> Even if all the snow were burnt, ashes would remain.
--
JP Morris - aka DOUG the Eagle (Dragon) -=UDIC=- DOUG-15 AT bigfoot DOT com
Fun things to do with the Ultima games (http://ithe.cjb.net)
Developing a U6/U7 clone (http://fly.to/ire)
d+++ e+ N+ T++ Om U1234!56!7'!S'!8!9!KA u++ uC+++ uF+++ uG---- uLB----
uA--- nC+ nR---- nH+++ nP++ nI nPT nS nT wM- wC- y a(YEAR - 1976)
- Raw text -