Message-ID: <38FCB4D5.B3BB6044@bigfoot.com> From: "J.P. Morris" Organization: Aircraft Liberation Front X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14-15mdk i586) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.os.msdos.djgpp Subject: Re: dead beef References: <38FC4A45 DOT 54C24CDF AT bigfoot DOT com> <8dhrpn$q3s$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 75 Date: Tue, 18 Apr 2000 20:17:41 +0100 NNTP-Posting-Host: 212.56.119.112 X-Complaints-To: abuse AT plus DOT net DOT uk X-Trace: stones 956085289 212.56.119.112 (Tue, 18 Apr 2000 20:14:49 BST) NNTP-Posting-Date: Tue, 18 Apr 2000 20:14:49 BST To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Hans-Bernhard Broeker wrote: > > J.P. Morris 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)