Sender: nate AT cartsys DOT com
Message-ID: <35C73C57.1C3A06DA@cartsys.com>
Date: Tue, 04 Aug 1998 09:52:39 -0700
From: Nate Eldredge <nate AT cartsys DOT com>
MIME-Version: 1.0
To: "Gurunandan R. Bhat" <grbhat AT unigoa DOT ernet DOT in>
CC: Martin Str|mberg <ams AT ludd DOT luth DOT se>, djgpp AT delorie DOT com
Subject: Re: fsdb crashes post emacs
References: <Pine DOT LNX DOT 3 DOT 91 DOT 980804051135 DOT 5934A-100000 AT aditya DOT unigoa DOT ernet DOT in>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Gurunandan R. Bhat wrote:

> > : xorl    %%al, %%al
> >
> > How did you correct it? xorb or %%eax? And where (line number)?
> 
> Actually there is only one occurence of this staement in fullscr.c and
> a simple search will get you a line number. Unfortunately, the machine
> where I work is very far from the machine where I mail. I changed it thus:
> 
> xorb    %%al, %%al

If you look at the context, it is obvious that that's correct instead of
%%eax.

> I have now built fsdb by linking in malloc by hand and with the -g option.
> I now have some understanding of what is happening. As Eli correctly
> reasoned (without the benefit of an unstripped malloc and -g!!) one member
> of the linked list maintained by malloc/free points somewhere in the
> region of Mars.  In terms of malloc's variables,
> 
> op->ov_next = garbage
> 
> so that when this member is handed out to the application dereferencing
> it causes the crash. I am currently using (learning) gdb to go through the
> code and will report progress if any.

You might find it useful to compile `malloc' with -DRCHECK (think that's
right).  That turns on some redundancy checking, magic number bounding,
etc.

You may also be able to set a `gdb' watchpoint on that location.  It
seems the crash takes place before `fsdb' even starts debugging, so
Eli's warnings may not apply.
-- 

Nate Eldredge
nate AT cartsys DOT com