From: Joseph Morris Newsgroups: comp.os.msdos.djgpp Subject: Re: dead beef Date: Wed, 19 Apr 2000 23:45:36 +0100 Lines: 114 Message-ID: <38FE3710.57CEFA8C@bigfoot.com> References: NNTP-Posting-Host: jpmorris.force9.co.uk (212.56.119.112) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: fu-berlin.de 956184323 8355733 212.56.119.112 (16 [28722]) X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14-15mdk i586) X-Accept-Language: en To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Eli Zaretskii wrote: > > On Tue, 18 Apr 2000, J.P. Morris wrote: > > > 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. > > What VM is that? SEER. I'm beginning to think that it might be causing the problem. It never was very stable. I think that when I re-wrote the program to use Allegro instead of a kludge for portability, the bug started to overwrite a more important area of memory. Even before, there were some crashes but very, very rarely. > > > 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? > > It suggests that move_object, or one of its subroutines, is the > culprit. Perhaps it overwrites some array, or frees an object that is > still used by some other code after it is already free'd. > > > 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. > > You still haven't posted a single crash message. Why? It's possible > there are valuable hints there that you are overlooking. Please don't > hide information from us. Okay, but it's rather long: Program log: Calling VRM: mainproc Init main game engine Starting main game engine BUG: FOREIGN OBJECT 0x203202 DETECTED BUG: Was passed as a parameter from function SIT_DOWN BUG: Probing object: BUG: o->name = beefdead: ============= OB_Check() has just printed o->name in hex, so we see it's 0xbeefdead. Next thing it tries to print o->name as a string and dies, hence the crash in __doprnt and _vsprintf below. OB_Check was called by check_object, which is a bridge between the VM and my functions in the 'real world'. check_object was called by callfunc, which is used by SEER to call 'real world' functions outside of VM-space All of which which suggests that the crash is happening inside the SEER library. eax=00000001 ebx=00000000 ecx=00000073 edx=beefdead esi=ffffffff edi=00252d7c ebp=00251d08 esp=00250910 program=C:\IRE\IRE.EXE cs: sel=00a7 base=10000000 limit=010cffff ds: sel=00af base=10000000 limit=010cffff es: sel=00af base=10000000 limit=010cffff fs: sel=00c7 invalid gs: sel=00bf base=00000000 limit=0010ffff ss: sel=00af base=10000000 limit=010cffff App stack: [0025323c..001d323c] Exceptn stack: [001d3180..001d1240] Call frame traceback EIPs: 0x000f1086 __doprnt+2266 0x000e379b _vsprintf+43 0x000021f2 _Bug+34, line 421 of console.c 0x00004f60 _OB_Check__FP6OBJECT+224, line 94 of linklist.cpp 0x0002a756 _check_object+22, line 2165 of seer.cpp 0x0009e038 _callfunc+76, line 265 of callasm.c 0x0009bd71 _scStandardDispatcher+65, line 75 of script.c 0x00028c03 _call_vrm+87, line 569 of seer.cpp 0x0009e038 _callfunc+76, line 265 of callasm.c 0x0009bd71 _scStandardDispatcher+65, line 75 of script.c 0x0000c73e _startgame__Fv+1234, line 343 of mainloop.cpp C:\IRE>symify -o out3 ire.exe ================= Ideally I'd like to get rid of Seer, at least temporarily, so I can see if it is responsible. But it is the backbone of the entire program, I'd need to find a scripting language with a C-like syntax, preferably one that supports compilation into byte-code, rather than on-the-fly interpretation. Performance is pretty important. Does anyone know a site which compares realtime scripting languages? I've only found sites dedicated to non-realtime languages so far. In the meantime I will try and make the program run inside fsdb. -- 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)