From: dcasale AT my-deja DOT com
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Debugger that can detect buffer overruns?
Date: Fri, 17 Nov 2000 22:04:09 GMT
Organization: Deja.com - Before you buy.
Lines: 52
Message-ID: <8v4a0k$9fo$1@nnrp1.deja.com>
References: <8v3s96$ssh$1 AT nnrp1 DOT deja DOT com> <3A158FAF DOT 629A8FC8 AT cyberoptics DOT com> <83g0kq5myi DOT fsf AT mercury DOT st DOT hmc DOT edu>
NNTP-Posting-Host: 199.249.234.30
X-Article-Creation-Date: Fri Nov 17 22:04:09 2000 GMT
X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
X-Http-Proxy: 1.1 x51.deja.com:80 (Squid/1.1.22) for client 199.249.234.30
X-MyDeja-Info: XMYDJUIDdcasale
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

In article <83g0kq5myi DOT fsf AT mercury DOT st DOT hmc DOT edu>,
  Nate Eldredge <neldredge AT hmc DOT edu> wrote:
> Eric Rudd <rudd AT cyberoptics DOT com> writes:
>
> > dcasale AT my-deja DOT com wrote:
> >
> > > I'm pretty sure this indicates either an uninitialized pointer or
> > > a buffer overrun somewhere which is laying an egg which hatches
> > > later on.  Any ideas on debugging this?
> >
> > This type of bug can be exquisitely frustrating to find.  Watcom
> > has a function called _heapwalk() that one can use to traverse the
> > heap data structure.  It examines the information that malloc() had
> > placed in the heap, and detects various errors, such as when an
> > array overflow had overwritten the heap structure.  One can do a
> > heap walk at several strategic locations in one's code, and detect
> > the point at which the "egg" was laid, rather than just waiting for
> > it to hatch.  (In my experience, these bugs behave more like land
> > mines than eggs ;-)

Heh.  Hear, hear.

> > I've often wished that DJGPP had such a heap walk function, or, even
> > better, one that simply reported on the integrity of the heap
> > structure.  Unfortunately, I don't understand the operation of
> > malloc() well enough to know how to write such a piece of code.

Well, one thing I tried doing was adding the malloc.c module from the
library code to my compression program and turning on its DEBUG
define.  My program ended up crashing in the startup code.  *sighs*

> YAMD can find these bugs.

The catch being, of course, that one has to wait until one does a new
or delete to find the egg/land mine!  My program does some repeated
allocation and deallocation that causes YAMD to run out of memory very
quickly.  I'm now trying to recreate the error with a smaller fileset,
but YAMD isn't helping.  I've gotten it to fail once, but malloc and
free up to that point was kosher, according to YAMD.

I want to be able to check the integrity of allocated buffers _on the
fly_.  Since I've _finally_ been able to locate the malloc source code,
buried several levels deep in the gnu directory structure, I might
decide to try my hand at a heap walker, like Eric was talking about.

Damon Casale, damon AT WRONG DOT redshift DOT com
"Don't move."  *points*
"I stepped on WHAT!?" -- two guys in some old war movie


Sent via Deja.com http://www.deja.com/
Before you buy.