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

Tue Jan 17 18:36:00 GMT 2006

Hans Boehm wrote:
> 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.
>
I have a simple patch to change this that I will be submitting soon. 
The fact that you get different configurations in a cross build and a 
native build with the same configuration parameters is a little 
disconcerting.
David Daney.
> 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
>>>>