[Gc] leak with finalizers

Paolo Molaro lupus at debian.org
Wed Dec 22 13:29:38 PST 2004

On 12/22/04 Boehm, Hans wrote:
> Did you see a growing leak?

Yes, it gets fairly quickly to 180 megabytes in under a minute,
then it slows down a bit and leak about 100 MB per minute.
I stopped it at 400 MB.

> If so, I can't reproduce the problem.  I saw the process stabilize at
> anywhere between 17 and 58MB.  This was under Linux, on IA64 and X86.

I'm running it under Linux x86 (kernel 2.6.8ish and nptl) and Linux/ppc
with linuxthreads.

> 17 Megabytes looks reasonable to me.
> I did not yet investigate why it takes 58MB in some cases.  That does seem
> high.  On the other hand, this benchmark is such that a few old pointers
> left around on the stack could drastically affect memory use.  And I
> got the higher numbers after enabling threads, which might cause certain
> stack locations not to be overwritten regularly.  And the finalization
> count reflects the fact that a few lists are still being considered
> live.

I used the debian package and it has thread support enabled, though
it shouldn't matter much, since the app doesn't use threads. The stack
locations should get overwritten at each loop, at least the ones in main()
so at most an object or two should not be collected (when the list
is zeroed).
If it helps, allocating the obj->array with GC_malloc_atomic()
makes things much worse, it got to 400 MB in 20 seconds (but this may be
because it just allocates faster).

> If you were seeing this on Windows, could you retry with 6.4, and see
> if it's fixed there?

Sorry, I forgot to mention it in the first mail, but no windows involved here.

> (Even on Linux, that might be interesting, since the GC_words_wasted
> calculation was wrong in 6.3, and that could make s difference, though
> I didn't actually see much of that.)

I didn't know about the 6.4 release, maybe I missed the mail.
Just downloaded: it's a bit better, with GC_malloc_atomic() it
gets to 400 MB in a minute, instead of 20 seconds.
Attached the log from GC_DUMP_REGULARLY (with GC_malloc_atomic()
for obj->array and GC_no_dls TRUE, to make sure that is not causing
mem retention).


lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gc.log.gz
Type: application/octet-stream
Size: 13022 bytes
Desc: not available
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20041222/531066ed/gc.log.obj

More information about the Gc mailing list