GTK+ is not Valgrind-friendly

[Paul Pogonyshev <pogonyshev gmx net>]

Hi.

I'm developing an application that uses GTK+ for GUI part.  I find Valgrind to
be very useful in detecting memory access errors and leaks.  However, GTK+
leaves lots of unfreed memory at process termination, which makes Valgrind
output for a GTK+ application way less usable and clean.  I have about 1 MB of
unfreed memory in about 140--150 loss records after a typical run of my program.

I'm willing to contribute to GTK+ project and make it more Valgrind-friendly.

I understand that freeing memory is not instant.  Freeing a megabyte of memory
allocated in thousands of small pieces could be quite slow (don't know how slow
and if it would be noticeable).  If this is considered an important factor, it
can be done like this:

A new global function is declared, say gtk_free_all_memory().  This function is
not required to be called and it's up to each programmer to decide whether to
invoke it upon program termination.  It should be guarded with some preprocessor
symbol to avoid unnecessary dependancies on new GTK+ versions.  A program that
is wanted to have "cleaner" memory profile could then look like this:


int
main (int argc, char *argv[])
{
  gtk_init (&argc, &argv);
  gtk_main ();

#if GTK_HAVE_FREE_ALL_MEMORY
  gtk_free_all_memory ();
#endif

  return 0;
}


The new function would call internal cleaners for some modules that would free
allocated memory.  For instance, `gtkmain.c' creates a GdkDisplay with a call
to gdk_display_open_default_libgtk_only().  The display is never freed and this
is accountable for many of the 150 loss records I have.

Please let me know if you are interested in this and if I should start working
on the project.  Maybe you have some suggestions or maybe my ideas don't fit
your views on GTK+ development completely.  I want to help but it's of course
not in my interesests to waste lots of time only to find that you don't want
such contribution.

Just to start with something I made a small patch to close one particular memory
leak.  Having written it I discovered that it's useless in the default case
exactly because the default display is not closed.  Still the patch should be
useful since there are ways to open and close more displays.

Paul Pogonyshev



Index: gdk/x11/gdkevents-x11.c
===================================================================
RCS file: /cvs/gnome/gtk+/gdk/x11/gdkevents-x11.c,v
retrieving revision 1.130
diff -u -p -r1.130 gdkevents-x11.c
--- gdk/x11/gdkevents-x11.c	23 Apr 2004 13:03:56 -0000	1.130
+++ gdk/x11/gdkevents-x11.c	30 Apr 2004 00:27:56 -0000
@@ -2518,6 +2518,13 @@ struct _NetWmSupportedAtoms
   gulong n_atoms;
 };
 
+static void
+free_net_wm_data (NetWmSupportedAtoms *supported_atoms)
+{
+  if (supported_atoms->atoms)
+    XFree (supported_atoms->atoms);
+}
+
 /**
  * gdk_x11_screen_supports_net_wm_hint:
  * @screen: the relevant #GdkScreen.
@@ -2560,7 +2567,8 @@ gdk_x11_screen_supports_net_wm_hint (Gdk
   if (!supported_atoms)
     {
       supported_atoms = g_new0 (NetWmSupportedAtoms, 1);
-      g_object_set_data (G_OBJECT (screen), "gdk-net-wm-supported-atoms", supported_atoms);
+      g_object_set_data_full (G_OBJECT (screen), "gdk-net-wm-supported-atoms", supported_atoms,
+			      (GDestroyNotify) free_net_wm_data);
     }
 
   fetch_net_wm_check_window (screen);