(replying to myself)
On Tue, 2004-09-21 at 00:58, MenTaLguY wrote:
On Sun, 2004-09-19 at 21:24, bulia byak wrote:
I just checked in this change to CVS.
This does not help unfortunately.
Interesting. It should have some. I wonder whether finalizers are getting called at all... :/
It seems they are not. In fact, Inkscape::GC::Finalized objects are simply not getting collected.
It looks like I made another really dumb mistake -- an I::G::F object, when created, needs to register a callback function to handle its cleanup before it is collected.
The problem? It saves a pointer to itself as a parameter, so the collector sees there is still a pointer to it and never collects it or any other objects it points to.
The correct approach is to save an integer offset relative to a base address instead, as is done by the (roughly equivalent) gc_cleanup class that ships with libgc.
So ... most or all of the leakage is coming from the libc heap, not boehm's. I guess that exonorates the collector itself, though the shim code and other changes I made to the tree to accomodate it are still suspect.
I::G::F = shim code
Some I::G::F-derived classes allocate chunks of memory from the traditional heap too -- notably the NRArena stuff, which is used so heavily by export -- so this could easily be bloating the malloc() heap.
I'll commit this and we'll see if it fixes everything.
-mental