> > > I might be a bit of a puritan but I am puzzled about the following. > Running > > valgrind over my program I noticed a lot of unfreed block on application > > close. I decided to run a basic GTK program and see what happened. > > I do this a lot on Chrome. First, as described in > http://library.gnome.org/devel/glib/stable/glib-running.html > be sure to set G_SLICE=always-malloc, else > valgrind might get a bit confused. Second, there are > dozens of problems in system libraries that you > should probably just ignore. > Try grabbing > http://src.chromium.org/viewvc/chrome/trunk/src/tools/valgrind/suppressions.txt > and using part 1 of that (the non-chrome-specific part); that > should suppress lots of them.
G_SLICE=always-malloc is a must if you want to run it under valgrind, so that all g_malloc() and friends do not use Glib's slice allocator, which currently messes up valgrind's output. Anyway, lots of the memleaks reported are due to things initialized in gtk_init() which are never de-initialized (and similar functions). There is no gtk_deinit() to clean all initialized things. I run with the same problem everyday when using just g_type_init() in my Glib/GObject based apps, lots of things initialized and never deinitialized in a clean exit. You just need to get used to Glib/GTK's "memleaks", which usually are still-reachable when app ends. Truth be told, they are not really "memleaks", but just memory that should be allocated as long as the program runs (like memory for the type system supporting GObjects). Having a g_type_deinit() or gtk_deinit() function which cleanly deallocates all stuff previously allocated in g_type_init() or gtk_init() would be very helpful for memleak checking in Glib/GObject/Gtk based apps, but just that, helpful, not critically needed. Another good option could be to create specific valgrind-suppressions files to skip all these messages reported as memleaks which are not really "true" memleaks, but I think it's quite complex to build a unique whole suppressions file for all possibilities under glib/gobject/gtk. BTW, if anyone has a better way of tracing memleaks in glib/gtk based apps, without valgrind or using it in another way, steps are welcome! Cheers -Aleksander
_______________________________________________ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
