GNOME Bugzilla – Bug 383340
Memory leaks under win32 and VS2005
Last modified: 2007-01-25 09:50:31 UTC
Please describe the problem: The gtkmm stable release leaks memory after an application exits. Steps to reproduce: 1. Create an simple win32 project with the following main function : #include <gtkmm.h> #include <windows.h> #include <crtdbg.h> int main( int argc, char* argv[] ) { _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); Gtk::Main kit(argc, argv); return 0x0; } 3. observe memory leaks in debug output window when executed in the vs2005 debugger Actual results: The above code does the following: _CrtsetDbgFlag() instructs the platform sdk to track all allocations and to dump a report of all unfreed allocations at the exit of the program ( this happens after all process-owned dlls are unloaded from the process memory space and all global variables are gone and the process is ready to be closed ). The other two lines should be self-explanatory. Expected results: You see about 18 memory leaks in the debug output window of vs2005. Does this happen every time? Yes Other information: In the above reproduction case, the Gtk:Main objects leaks memory only once. Executing it in a loop does not introduce more memory leaks, so the impression of memory belonging to static/global objects is not being freed comes to mind. A more elaborate test case can be found under http://rainestorm.org/craine/gtkmm_memleak.zip
> You see about 18 memory leaks in the debug output window of vs2005. Could you attach those results here as a text file, please. I guess it's possible that we allocate static stuff and don't free it. Normally that wouldn't be an issue. Do you have a need for a cleanup function, to explicitly release such objects?
Bug confirmed. First let me point out that this bug can only be reproduced with Visual C++ (crtdbg.h is not available for mingw32). Second, I ran this example through a memory leak detection tool (http://www.codeproject.com/tools/leakfinder.asp). Log report is attached to this comment. Looks like memory leaks occurs in glib\glibmm\wrap.cc(98) and glib\glibmm\error.cc(138). Are Error::register_cleanup() and wrap_register_cleanup() correctly called ?
Created attachment 77958 [details] LeakMem log report
I don't think Glib::wrap_register_cleanup() and Glib::Error::register_cleanup() are called at all. I didn't know they existed. Possibly calling these would free the memory. If necessary, we could create one these in one Gtk::deinit() function that calls these, though there might be GTK+ stuff that should also be released. But again, I don't think this is generally necessary. I guess it might be an issue if you are using gtkmm in an in-process plug-in.
Created attachment 78016 [details] vs2005 debug allocation output
Created attachment 78017 [details] vs2005 debug allocation output attached the debug output the vs2005 debugger spits out for a simple gtkmm test program ( mem leak report at the end )
Created attachment 78018 [details] allocation callstack information attachment contains callstack information for all allocations reported as leaks
Created attachment 78019 [details] vs2005 sample project which causes memory leaks attached a vs2005 sample project which reproduces the memory leaks
> But again, I don't think this is generally necessary. I guess it might be an > issue if you are using gtkmm in an in-process plug-in. > These leaks are always reported, independent of the way you actually use gtkmm and therefore can be confused with the leaks that may be reported by the application one is trying to debug. The crt debugging flags are a somewhat standard method of finding memory allocation issues under win32. A cleanup method/function that frees these allocations would be greatly appreciated from my side. Christopher Raine
Could you try calling Glib::wrap_register_cleanup() and Glib::Error::register_cleanup()?
> Could you try calling Glib::wrap_register_cleanup() and > Glib::Error::register_cleanup()? > This works. There are no reported memory leaks anymore if you call these two functions. The only issue to get this to work was that you have to ensure that the Gtk::Main object has already been destructed before calling the above functions. Just for the record in case anybody else stumbles upon this, you have to do the following : int main(int argc, char *argv[]) { _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); // enclose the Gtk::Main object in a local scope { Gtk::Main kit(argc, argv); } // call the clean up functions after the Gtk::Main object has been destroyed Glib::Error::register_cleanup(); Glib::wrap_register_cleanup(); return 0; } Thank you for your help. For me, this bug is not an issue anymore.
Actually, this cleanup should happen automatically. This unexplained change seems to be guilty: http://svn.gnome.org/viewcvs/gtkmm/trunk/gtk/src/main.ccg?rev=74&r1=29&r2=74
Fixed in SVN trunk, I believe.