Sender: nate AT cartsys DOT com
Message-ID: <3766B04B.9181AC61@cartsys.com>
Date: Tue, 15 Jun 1999 12:58:03 -0700
From: Nate Eldredge <nate AT cartsys DOT com>
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.10 i586)
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Re: What about the registers????
References: <Pine DOT SUN DOT 3 DOT 91 DOT 990615094408 DOT 2646D-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com

Eli Zaretskii wrote:
> 
> On Mon, 14 Jun 1999 north AT iname DOT com wrote:
> 
> > While taking your advice and debugged whith a couple of printf's and
> > using the stack window in Rhide I found that the GPF was caused by
> > a cfree(*pointer)-function.
> >
> > 'call frame traceback
> >  in function free+275
> >  in function cfree+12
> 
> This usually means that your program overwrites some buffer allocated
> from malloc/calloc.  malloc and free maintain some crucial information
> about the memory pool as hidden pointers immediately before the
> address they return to you; if you overwrite that information, free
> will blow up.
[snip]
> I suggest to look carefuly at your code for some fragment that writes
> beyond the limits of an allocated buffer.  If the crash happens at a
> constant address, and if the data in the registers at the point of
> crash is the same each time it crashes, the best way to hunt down this
> problem is to put a data-write breakpoint (a.k.a. watchpoint) at the
> address which causes the crash, and then when your program overwrites
> that address, the debugger will catch it red-handed.

<plug>
You could also try YAMD, a malloc debugger which I wrote, that
effectively does this for you.  It will catch the program when it tries
to go out of bounds.

http://www.cartsys.com/eldredge/n/yamd/

</plug>
-- 

Nate Eldredge
nate AT cartsys DOT com