GTK, Purify, some patches, etc.

["Bruce Mitchener, Jr." <bruce puremagic com>]

Hello.

I'm currently running Purify against Mozilla and have found some memory
errors in GTK.  Those errors I will report after some further investigation.
I've gone further and am running Purify against testgtk and have a couple of
small patches.  There are additional problems that I haven't yet had the
opportunity to look into, but will try and send out descriptions of the
problems.  Some of them may be specific to Solaris.

Index: gtkitemfactory.c
===================================================================
RCS file: /cvs/gnome/gtk+/gtk/gtkitemfactory.c,v
retrieving revision 1.23
diff -u -r1.23 gtkitemfactory.c
--- gtkitemfactory.c 1999/03/15 00:03:22 1.23
+++ gtkitemfactory.c 1999/03/17 05:46:59
@@ -684,6 +684,7 @@
   for (slist = ifactory->widgets_by_action; slist; slist = slist->next)
     g_free (slist->data);
   g_slist_free (ifactory->widgets_by_action);
+  g_free(ifactory->path);
   ifactory->widgets_by_action = NULL;

   parent_class->destroy (object);

Index: gtktipsquery.c
===================================================================
RCS file: /cvs/gnome/gtk+/gtk/gtktipsquery.c,v
retrieving revision 1.16
diff -u -r1.16 gtktipsquery.c
--- gtktipsquery.c 1999/02/24 07:36:38 1.16
+++ gtktipsquery.c 1999/03/17 05:46:40
@@ -257,6 +257,9 @@

   gtk_tips_query_set_caller (tips_query, NULL);

+  g_free(tips_query->label_inactive);
+  g_free(tips_query->label_no_tip);
+
   if (GTK_OBJECT_CLASS (parent_class)->destroy)
     (* GTK_OBJECT_CLASS (parent_class)->destroy) (object);
 }


In gdk_xpm_destroy_notify(), it has a local variable 'color' of type
GdkColor.  It passes this to gdk_colormap_free_colors() which passes it to
g_hash_table_remove() and then to gdk_color_equal().  In gdk_color_equal(),
it attempts to read the fields 'red', 'green' and 'blue' on the color, but
they were never initialized and Purify gives an unitialized memory read
error in gdk_color_equal().

When running testgtk, grabbing a target in the 'Selection Test' and dragging
it yields an uninitialized memory error in gtk_list_motion_notify().  This
appears to be the reading of event->window in that code.  Should it be
initialized to event->window = list->window along with the other
initializations for 'event' in gtk_list_vertical_timeout()?

That same test also appears to leak 4 bytes of memory.  That memory was
allocated in XGetWindowProperty() as called by gdk_selection_property_get()
(which was called by gtk_selection_notify()). Actually, this was a 1 byte
leak, which happened 4 times during my testing of that test.  Looking again,
it leaks 1 byte on each click of the 'Get Targets' button.

gdk_init() on my system ends up calling gdk_im_open().  However, gdk_exit()
doesn't call gdk_im_close().  Should it?

When doing the 'Layout' test, it appeared to leak from
gtk_layout_set_adjustments(), where it called and allocated
gtk_adjustment_new().

In the 'clist' test, when called by 'create_clist()' and
'insert_row_clist()' from testgtk, there uninitialized memory read errors
from the 'requisition' variable in gtk_clist_set_cell_style() where it has a
value read from it and passed to column_auto_resize().

the font selection test should g_free() the result of the call to
gtk_font_selection_dialog_get_font_name().  Currently, it leaks (just to
provide a good example).  gtk_clist_set_shift() has the same uninitialized
memory read as gtk_clist_set_cell_style() as described above, when called by
gtk_font_selection_init().

testgtk doesn't initialize the variable 'transparent' for the ctree test, so
uninitialized memory read errors occur in gdk_gc_set_foreground() where this
value is read.  What is a valid value for transparent here?

The 'color selection' test had the most problems.  When bringing it up and
then hitting 'cancel', some very bad things happened. a 'gtk_style' has what
seems to be a refcounting issue.  It is freed multiple times and a lot of
'free memory read', 'free memory write' and 'freeing unallocated memory'
errors occurred in 'gtk_style_unref()'.

That's all of the errors, excepting some that appear to be OS-specific that
I noticed via Purifying the 'testgtk' application.

The more serious of the OS-specific errors is the apparent
multiple-destruction of input contexts used for any text entry widgets.  I'm
looking to confirm whether this is a Solaris 2.6 bug or a GTK bug yet.

 - Bruce