mental at rydia.net
mental at rydia.net
Thu Feb 3 17:09:55 PST 2005
Quoting John Plevyak <jplevyak at acm.org>:
> I was wondering if anyone was working on getting the GC
> to work with valgrind (valgrind.kde.org)?
> I am interested in any partial patches, experiences,
> or pointers.
> I would like to build a minimally invasive patch to the GC
> which could be encorporated into the general release.
In principle the collector should work with valgrind already (I've used it
successfully in the past), although you will need to build an appropriate
suppression profile so the collector scanning uninitialized memory (unavoidable
and harmless) won't generate any warnings.
The one libgc modification that is rather needed is for libgc to call
VALGRIND_MALLOCLIKE_BLOCK and VALGRIND_FREELIKE_BLOCK, as currently you don't
get the nice allocation tracking that you would with the system allocator.
Unfortunately, as I discovered earlier this week, it looks like the /proc change
introduced in libgc 6.4 has broken libgc under valgrind (causing libgc to
segfault when it tries to scan some range of memory that valgrind doesn't
like). I've not had time to look into that in depth though.
If you immediately need to valgrind a libgc-using application with libgc 6.4,
you might want to think about employing the approach Inkscape uses for
integrating libgc: we have a vtable of allocator operations which is populated
on startup based on the value of an environment variable.
One setting of the environment variable ("disable") populates the vtable
with calls to the system allocator rather than libgc's. That configuration
obviously leaks memory, but it is still useful for checking things with
valgrind or ruling out libgc bugs.
See src/gc-core.h and src/gc.cpp in the Inkscape source tree for details of
 Another option is "debug", which lets us use the libgc debugging allocator
without requiring a recompile. The default, "enable", just uses the normal
More information about the Gc