[Gc] GC as leak detector

Juan Jose Garcia Ripoll lisp at arrakis.es
Tue Oct 11 10:25:31 PDT 2005


To summarize, the problem was that I am using the Boehm-Weiser garbage
collector to manage the memory from a C++ program and in the process
detect memory leaks. In my program I use mostly GC_debug_malloc[_atomic]
and after running for some time the collector begins to produce messages
of the form

Testing minimizer (no truncation,norml svd,1-site):
===================================================
Mag. field,obc,t.i ........................................
Leaked atomic object at start: 0x81b10c0, appr. length: 64
Leaked atomic object at start: 0x81b1280, appr. length: 64


On Mon, 2005-10-10 at 14:49 -0700, Boehm, Hans wrote:
> I expect there should be very few, and possibly no, calls to
> GC_malloc_atomic in your environment, possibly aside from those
> introduced by your operator new.  Can you put a breakpoint there, and
> see who might be allocating "atomic" objects? 

My program only calls the GC_debug routines. Furthermore, I think I have
conclusive evidence that the "leaked" memory is allocated by my program
using the GC_debug_malloc_atomic routine. I have  introduced
	#define GC_debug_malloc_atomic GC_debug_malloc
at the beginning of my headers and now all the leaks are marked as
composite:

Testing minimizer (no truncation,norml svd,1-site):
===================================================
Mag. field,obc,t.i ........................................
Leaked composite object at start: 0x81b10c0, appr. length: 64
Leaked composite object at start: 0x81b1280, appr. length: 64

This means that the memory leaked is allocated with debug information
but somehow this information is lost.

Regards,

Juanjo



More information about the Gc mailing list