On Sun, 2004-09-19 at 01:05, MenTaLguY wrote:
For example it makes previews in the open dialog unusable: each preview loads the document, and since the memory is not freed, it quickly eats up all available memory as you go through the files in a directory. Just go through a couple dozen files, and you're lucky if you manage to kill Inkscape before it bogs the system down to a complete halt.
This sounds like a good steps-to-reproduce. Thanks.
Ok, I have at least partly tracked this down.
It looks like the SPDocuments created for the previews never get freed. I set breakpoints in gdb, caught one document as it was created, and saved a pointer to it in a temporary location. Then I clicked on several other files and got previews.
The older preview document remained live, and its GObject::ref_count never dropped below 1.
Apparently setFileName() creates a document, but neglects to release its ref on that document when it is finished.
SPDocuments, like all refcounted objects in Inkscape, are created with an initial refcount of 1. In general, this means you ought to do this sort of thing:
foo = create_foo(); // create a foo ... // do what we need to do with foo bar->withFoo(foo); // can take its own reference if it needs to ... // do anything else we need to do with foo unref_foo(foo); // we should let go of our reference now
It's the equivalent of the last line that was missing here.
There are probably other similar leaks throughout the codebase. I remember having to fix several such leaks in repr-related code a while back.
SPDocuments just happen to be the worst possible (and most noticable) case, since a single document references a LOT of memory.
I've comitted a fix for this to CVS; see if things get any better for you. I expect there are more layers to this particular problem.
-mental