[Gc] leak with finalizers

Paolo Molaro lupus at ximian.com
Fri Dec 24 03:03:40 PST 2004

On 12/22/04 Boehm, Hans wrote:
> I think I sort of understand the problem, and NPTL doesn't have much to do with
> it.  The example just seems to be at the edge of causing this behavior,
> and something about NPTL or one of the newer libraries pushes it over.

It's also weird that if constant-size array are created, it works ok.

> The problem is that it gets in a mode in which a garbage collection
> reclaims very little, since everything is finalizable and can't
> actually be collected.  Thus the next collection finds a small
> GC_words_allocd value, decides the heap is too small, and grows.
> Since the heap has grown, GC frequency decreases, more finalizable
> stuff gets allocated between GCs, etc.

Thanks for looking into it.

> If you set GC_MAXIMUM_HEAP_SIZE to a reasonable value, everything
> is OK.

Yep, confirmed. Sadly the C# example has a slightly different patterns and
eventually it will go out of mem anyway. I'll try to reproduce with a C
program. Adding a GC_gcollect() at the right place in the C# code makes it 
work fine, too, so it seems to be very sensitive to the time a collection 

> I wouldn't be surprised if other implementations had similar problems
> with such code.

The C# equivalente has been reported to work fine with the MS CLR.

> The workaround is to avoid finalization of objects that reference
> huge amounts of memory.  If possible, finalize a smaller object that
> is referenced by the main object instead.

Unfortunately we can't ask our users to rewrite their code:-)


lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better

More information about the Gc mailing list