Mail Archives: djgpp/2000/11/17/17:15:30
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.
- Raw text -