This is the mail archive of the
mailing list for the GCC project.
Re: Status of GCC memory checking, -fcheck-memory-usage
- From: Claus Fischer <claus dot fischer at clausfischer dot com>
- To: Carlo Wood <carlo at alinoe dot com>
- Cc: gcc at gcc dot gnu dot org, AWLaFramboise at aol dot com, rra at stanford dot edu
- Date: Sun, 10 Feb 2002 18:07:35 +0100
- Subject: Re: Status of GCC memory checking, -fcheck-memory-usage
- References: <20020210122130.A956@clausfischer.com> <20020210175603.A30306@alinoe.com>
On Sun, Feb 10, 2002 at 05:56:03PM +0100, Carlo Wood wrote:
: What is inferior about libcwd as malloc debug library?
: If you care to clarify then I will fix it, whatever it is.
I've tried ccmalloc and dmalloc, so I apologize if the following
doesn't apply to the situation of libcwd.
What I miss with those libraries is the kind of bounds checking
that Checker can do. Usually malloc libraries either check
memory around an allocated region by placing magic bit patterns
around it and checking at the time of free, or at some pre-scheduled
times inbetween. An exception would be efence which uses VM tricks.
Both approaches have a problem: VM tricks are costly for many small
allocations, and magic numbers do not report the bounds violation
Since Checker's principal manner of operation is different (using
the -fcheck-memory-usage feature of gcc), it delivers error reports
right on spot, exactly when and where the out-of-bounds access is
The general drawback of Checker is that it's very slow.
It is, however, by far the most extensive and comprehensive
free tool in that class AFAIK.
: Sure, what libcwd misses is memory access checking: a check on EVERY
: memory access whether or not it is to initialized memory. But for
: that it needs hooks, generated by gcc/g++. It is these hooks that
: are now missing.
Those were in -fcheck-memory-usage if I understood correctly.
Claus Fischer <email@example.com>