Message-ID: <38FB70A3.18D96638@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: dead beef Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 43 Date: Mon, 17 Apr 2000 21:14:27 +0100 NNTP-Posting-Host: 212.56.119.112 X-Complaints-To: abuse AT plus DOT net DOT uk X-Trace: stones 956002284 212.56.119.112 (Mon, 17 Apr 2000 21:11:24 BST) NNTP-Posting-Date: Mon, 17 Apr 2000 21:11:24 BST To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com I have a complex game program which currently compiles in both DJGPP and Linux. Allegro 3.9.x is used to manage most of the platform-specific code. Under Linux, the program runs correctly for an indefinite period. Under DJGPP, however, it crashes between 9:00 and 11:00 game time, i.e. about 180-300 cycles of the game loop. The reason it crashes is that some of my pointers appear to be spontaneously changing, either to 0xA7 (which causes an RMCB fault) or to 0x20320?. The memory these refer to is filled with 0xbeefdead. I used the sbrk fill option to fill allocated memory with 0xdeadbeef, but the memory I'm using isn't memory I've allocated, because I have my own malloc() wrapper, which I used to try and find the rogue blocks. Does sbrk fill memory with DEADBEEF only during allocation, or also when memory is freed? I have made utterly sure that memory is being locked in my interrupt handlers. In addition I have also used fortify, which detects memory overruns. It has not detected any. Since each part of the program relies on something which has happened previously and the problems only manifest when the program is fully operational, I cannot effectively reduce the potential problem area. I would guess that the problem must be one of these: 1. A memory overrun of statically-allocated data (is there a tool to detect this?) 2. Memory overrun in a 3rd-party library 3. Memory is being used long after deallocation (NOT through M_get() or M_free() wrappers) 4. Superstitious explanation Does anyone recognise these symptoms, or another debugging technique? -- 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)