Message-Id:	<199808060134.CAA16926@sable.ox.ac.uk>
Comments:	Authenticated sender is <mert0407 AT sable DOT ox DOT ac DOT uk>
From:	George Foot <george DOT foot AT merton DOT oxford DOT ac DOT uk>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Date:	Thu, 6 Aug 1998 02:33:52 +0000
MIME-Version:	1.0
Subject:	Re: help! SIGILL?!?
Reply-to:	george DOT foot AT merton DOT oxford DOT ac DOT uk
CC:	djgpp AT delorie DOT com

On  5 Aug 98 at 9:32, Eli Zaretskii wrote:

> On Tue, 4 Aug 1998, George Foot wrote:
> 
> > It looks like you have overwritten part of your stack; the EBP and 
> > ESP values are similar enough to indicate that they themselves 
> > probably are correct, but the call frame traceback got nowhere.
> 
> This could be because the EIP itself is trash.  EBP and ESP look quite
> innocent to me, btw.

Yes, but the only reason for the traceback to stop after a single 
line would be for the content of the stack to be bogus.  Whatever EIP 
is, it is just printed as the first item on the traceback.  I don't 
think it affects the rest of the traceback at all.

> > The latest version of my post mortem debugger can do this for you.
> > To use this you need to install my core dump system too, which 
> > catches selected signals and writes a file called `core' to disk 
> > containing information about the program when it crashed, including a 
> > memory dump.
> > 
> > I've also written a signal handler that generates these reversed 
> > tracebacks.  If you're interested, I can send it.
> 
> Hey, George, that's wonderful news!  What's preventing you from
> submitting this for inclusion in v2.02?  Seems like a pretty important
> addition to me. 

I don't think it's currently user friendly enough to be included. The
core dumper is fine, I think, though there's always the possibility
that I've called some function I should not have called.  The 
debugger is functional, but isn't very user friendly.  It only had 
pretty basic features last time I uploaded it; I've added some more 
since then, but each time I do I can't help feeling that it would be 
better to get GDB to understand the core dumps.  I don't know 
anything about GDB though.

I'm also not sure that it would benefit much from being part of djgpp
directly.  It seems to work quite well as a separate module.  Since
I've only tested it on a few toy programs and an Allegro game, I
don't think it should be used by default.

That said, a few changes to the djgpp library code would make it 
possible for this to work better in a number of ways.  At the moment 
there's no way to find out the sizes of the DPMI memory blocks, 
unless the DPMI server supports __dpmi_get_memory_block_size_and_base 
-- but I haven't found a DPMI server that supports this yet.

> For example, I'm hunting a bug in Emacs which causes
> it to crash roughly once every 2 months; with core dumps, I imagine it
> would be much easier to find.

If you want to try it, I uploaded a version of it about six weeks ago 
to:

    http://users.ox.ac.uk/~mert0407/pmdb04s.zip

As I said, I've added a few new things since then, but this new 
version isn't ready to be distributed yet.

The `readme.txt' file explains most things, and the help system 
inside the debugger explains more about the debugger itself.  Please 
do let me know what you think about this.

-- 
george DOT foot AT merton DOT oxford DOT ac DOT uk

- Raw text -