Heap fragmentation (Was: Debugging "Leaks" With Boehm-GC)

Mon Jan 16 20:26:00 GMT 2006

NO_DEBUGGING seems to be set by the collector's configure.ac if it thinks
you are building a cross-compiler. I'm sorry I had forgotten about that.
You will need to build without NO_DEBUGGING, since that also prevents
GC_dump from being defined.
This facility was really meant to be used by either calling GC_dump
occasionally from either client code or the debugger, or setting the
environment variable, and having the collector do so implicitly on a
regular basis. GC_dump_regularly wasn't really meant to be externally
visible or set, though in fact there is nothing to stop you from just
assigning to it in C code. If we wanted to add a different mechanism for
setting it, we could add a setter to the GC.
Hans
On 2006年1月15日, Martin Egholm Nielsen wrote:
> >> A call to GC_dump() or setting the GC_DUMP_REGULARLY environment
> >> variable should tell you what's in the heap.
> > No, do you recall:
> > http://gcc.gnu.org/ml/java/2005-12/msg00083.html
> > setting GC_DUMP_REGULARLY doesn't affect anything - what should happen?
>> Oh, I found this:
>> # ifndef NO_DEBUGGING
> if (0 != GETENV("GC_DUMP_REGULARLY")) {
> GC_dump_regularly = 1;
> }
> # endif
>> So I guess NO_DEBUGGING must be defined in my case... Hence, a bit late
> to do it that way...
>> Then I should somehow find a way to set "GC_dump_regularly" - but
> there's no nice setter method for that one(?)...
> Any ideas?
> Recompile without NO_DEBUGGING (where is actually the correct place to
> remove this - some Makefile.*?)
>> // Martin
>>