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

Attilio Fiandrotti wrote:

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.


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 @@
+  g_object_unref (window);

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

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