On Tue, Jun 3, 2014, at 04:45 AM, neandertalspeople wrote:
As far as I understand one option could be adding a environment variable, something like DISABLE_GC or similar, then, as far as i know, to surround all the Inkscape::GC::XXX with #ifndef #endif.
Not sure if this would be a correct way to proceed and disable the garbage collector properly. I did a very small test, where i commented the calls to sp_main_gui and sp_main_console and also commented the Inkscape::GC::Init() line. Before commenting the GC init line, a few errors related to GC appeared when running valgrind, after commenting it, the errors disappeared.
Is that approach correct ? Or am i missing something here ?
That would disable the garbage collection, however it would then leave all the objects in memory and not collected at all. Essentially all allocated items would be left to dangling pointers... that is they would get new'ed and then forgotten so that they are never freed.
A better approach for now would be to look for objects left in memory that you would expect to have been cleaned up and then work your way up the ownership chain to see what is being held onto. Our document object might be a higher up place to start. Adding a g_message() in the ctor and dtor can help, and a static count per class too. Many of the objects that are not using the garbage collector *should* be cleaned up per normal Gtk/Gtkmm destruction, but accidental retention of a parent is blocking that. I believe there is some low-hanging fruit that the simple debug-dump approach can catch quickly.
In general Gtk+ and Gtkmm have clear ownership rules, and if we switch the remaining items from gc to follow those rules instead we should be good. Some of this will be via smart pointers, but other items need to just follow Gtkmm (including the manage() wrapper call).