Date: Thu, 20 Apr 2000 05:26:38 -0400 (EDT)
Message-Id: <200004200926.FAA15727@indy.delorie.com>
From: Eli Zaretskii <eliz AT delorie DOT com>
To: Joseph Morris <doug-15 AT bigfoot DOT com>
CC: djgpp AT delorie DOT com
In-reply-to: <38FE3710.57CEFA8C@bigfoot.com> (message from Joseph Morris on
	Wed, 19 Apr 2000 23:45:36 +0100)
Subject: Re: dead beef
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000419094705 DOT 10023L AT is> <38FE3710 DOT 57CEFA8C AT bigfoot DOT com>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


> From: Joseph Morris <doug-15 AT bigfoot DOT com>
> Newsgroups: comp.os.msdos.djgpp
> Date: Wed, 19 Apr 2000 23:45:36 +0100
>
> 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.

Yes.

> 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.

The crash is indeed in a function called by SEER, but the important
question is: who is responsible for putting garbage on the object that
triggers this print-out?

It is not clear at all (to me) that SEER's own code is responsible for
that.  I don't think there's any other way of being sure except
running under a debugger and catching the offender.

> eax=00000001 ebx=00000000 ecx=00000073 edx=beefdead esi=ffffffff edi=00252d7c
> ebp=00251d08 esp=00250910 program=C:\IRE\IRE.EXE

You edited out the first two lines of the crash message.  What were
they saying?

> 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

Wow!  The FS selector is invalid!  Do you have any idea why?  Does
SEER use the FS register?  If so, you want to check your code to make
sure you don't use FS in a way that interferes with SEER's usage.

> In the meantime I will try and make the program run inside fsdb.

GDB is a better choice for such complex problems.