[Gc] Memory leak without GC_collect()

Henning Makholm Henning at octoshape.com
Fri Apr 25 07:40:41 PDT 2008


> Since it requires that the destructor is called and changed all base
> classes gc into gc_cleanup.

There's your leak. The collector will only deallocate one layer of
finalizable objects in each collection. When a finalizer needs to run,
everything that is reachable from the finalizable object will be kept
alive until the next collection.

When you insert explict GC_collect() calls, collections will take place
often enough to brun through your finalizable structures fast enough to
keep up with allocations.

The relevant documentation makes clear that making everything (or even
a significant fraction of pointerful objects) finalizable is bad idea
with this collector. (It also argues that it is a bad idea in general,
for reasons of sane finalization orders in the presence of cycles).

Also note that

>>> Cycles involving one or more finalizable objects are never finalized.

so if you depend on finalizers to maintain object counts, you may end
up thinking more objects exist than actually do.

>  I know I shouldn't use gc6.8,

Huh? The GC website states:

>>> Usually you should first try to use gc_source/gc.tar.gz, which is
>>> normally an older, more stable version.

and gc.tar.gz is 6.7, which I therefore use without being ashamed.
Is it a worse thing to use 6.8?

--
Henning Makholm
OctoShape ApS



More information about the Gc mailing list