delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/04/19/18:13:11

From: Joseph Morris <doug-15 AT bigfoot DOT com>
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: <Pine DOT SUN DOT 3 DOT 91 DOT 1000419094705 DOT 10023L AT is>
NNTP-Posting-Host: jpmorris.force9.co.uk (212.56.119.112)
Mime-Version: 1.0
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)

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019