Re: Why do a gtk/directfb process grows bigger and bigger ?

[Attilio Fiandrotti <attilio fiandrotti gmail com>]

Attilio Fiandrotti wrote:
> Hi
>
> I recently noticed the the size of a generic gtk/dfb application 
> considerably grows over time while the same application, but compiled 
> for gtk/x11, does not.
>
> The attached example aplication permanently sets up a window and an 
> external box and at every proram's iteration a textview is created, 
> packed into the external box and then destroyed.
>
> Compiling for gtk/x11, the total amount of memory allocated by the 
> process remains constant, while under gtk/dfb the process image size 
> grown of some tens of KB every 3 or 4 iterations.
>
> I wonder what's the reason of this difference: am i doing something 
> wrong when i gtk_widget_destroy() the textview ? Is gtk/dfb leaking 
> somewhere ?

I was eventually able to fix the leak by unreferencing the window after 
destruction (see attached patch).

I did some tests with different GTK applications and noticed that this 
patch produces warnings later like

(gleak:4341): Gdk-CRITICAL **: gdk_window_process_updates: assertion 
`GDK_IS_WINDOW (window)' failed

so, i guess this patch only tackles the issue but does not properly.

As i'm not gtk/gdk expert i'd really apreciate if someone expert in this 
could help in working out a proper fix.

We're very close Debian Etch release, but ATM we're currently leaking up 
to 20 MB for a complete installation: if someone could give a hand on 
this we still may have a chance to patch our sources in time for Etch.

thanks

Attilio

attilio liberta2:~/gtkdfb/src/gtk+/gdk/directfb$ diff -u gdkwindow-directfb.c.orig gdkwindow-directfb.c
--- gdkwindow-directfb.c.orig   2006-12-18 11:37:58.000000000 +0100
+++ gdkwindow-directfb.c        2006-12-18 11:38:21.000000000 +0100
@@ -613,6 +613,7 @@
                impl->window->Close(impl->window);
        impl->window->Release(impl->window);
   }
+  g_object_unref (window);

 #if 0 /* let the finalizer kill it */
   if (!recursing && !foreign_destroy)