Date:	Tue, 23 Jan 2001 19:31:51 +0200
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	Martin Stromberg <eplmst AT lu DOT erisoft DOT se>
Message-Id:	<2593-Tue23Jan2001193151+0200-eliz@is.elta.co.il>
X-Mailer:	Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6
CC:	djgpp-workers AT delorie DOT com
In-reply-to:	<200101231436.PAA03507@lws256.lu.erisoft.se> (message from Martin
	Stromberg on Tue, 23 Jan 2001 15:36:40 +0100 (MET))
Subject:	Re: Debugging on 386
References:	<200101231436 DOT PAA03507 AT lws256 DOT lu DOT erisoft DOT se>
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> From: Martin Stromberg <eplmst AT lu DOT erisoft DOT se>
> Date: Tue, 23 Jan 2001 15:36:40 +0100 (MET)
>
> > > #1  0x3368 in __crt1_startup ()
> > > -> n
> > > Exiting due to signal SIGFPE
> > 
> > This one is not.  What does "disassemble analyse_ints" print near the
> > EIP of the breakpoint (0x1a64)?  Do you see any FP instructions
> > anywhere around that?
> 
> Nope. 00001a64 is a "cmpl" instruction. I'm at work now but I'll mail
> back the disassembly later.

Please do.  Given the session transcript you posted, it is quite
possible that the SIGFPE comes from some address *after* 0x1a64, since
__crt1_startup doesn't have line info, so GDB cannot step a line.

> > > #6  0x4e07 in __djgpp_exception_processor ()
> > > #7  0x1 in ?? ()
> > > #8  0x3368 in __crt1_startup ()
> > 
> > This is expected: the code which prints the traceback calls
> > _status87.  But what is that 0x1 on the stack?
> 
> Yes...?

It loks like something's not cleaning up the stack somewhere.  Hm.
Perhaps this is the cause of the strange recursive misbehavior.

> Well, the first mystery is the SIGFPE. There shouldn't be any SIGFPE
> signals coming at all...

Yes, if we establish that there's no FP instructions in the vicinity.

> > You are welcome to work on this, if you feel like it.  I'd be happy to
> > give directions if you do.
> 
> Please direct me.

It looks like it's important to understand where do those 0x1 and 0xc1
on the stack come from.  I'll try to think how to hunt that down.

- Raw text -