gtk_object_destroy and floating objects




Note: although I am getting to know the internals of gtk+, I am far from being
an expert and this might be something I did not understand.

This comes from a bug report from a GtkAda user (Ada binding to gtk+).

Apparently, there can be a memory leak in gtk+ in one particular case.
When one destroys an object that is still floating, its memory is not freed.
I think this is currently expected, since the object was not sinked and its
reference count is still 1 when gtk_object_destroy is called.
However, this means that the memory will never be freed for the object.

Admittedly, this is a very small case, since widgets are expected to have a
parent or be toplevel (and thus are no longer floating widgets, and the bug
does not occur). However, I believe that a simple test like

  if (GTK_OBJECT_FLOATING (object)) {
      UNSET_FLAGS (object, GTK_FLOATING);
      object->ref_count --;
  }

in gtk_object_destroy might help. Note that we can not use unref() since this
would actually attempt to kill the object and the rest of gtk_object_destroy
would raise an error...

Or maybe something like:

  if (GTK_OBJECT_FLOATING (object)) {
     UNSET_FLAGS (object, GTK_FLOATING);
     gtk_object_unref (GTK_OBJECT (object));
     return;
  }

would be cleaner (not tested though).


Here is a small test case. This is a direct translation of the Ada test case,
so there might be errors left, I am sure you will be able to understand my
point anyway :-). Sorry, I have never used the C version, even when I did the
GtkAda binding...

void main () {
   GtkWidget* win;
   GtkWidget* table;
   int i;

   gtk_main_init();
   gtk_window_new (GTK_WINDOW (win), gtk_window_toplevel);

   for (i=1; i<50000; i++) {
      gtk_table_new (table, 1, 1, 1);
        /*  gtk_container_add (GTK_CONTAINER (win), table); */
      gtk_object_destroy (table);
   }

}


If the line is left commented, the applications takes about 10Mb of memory.
If the line is uncommented, the maximum memory usage is down to about 2Mb.


Emmanuel



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]