Kalle Vahlman wrote: > 2006/12/18, Attilio Fiandrotti <[EMAIL PROTECTED]>: > >> 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 would say yes, calling gtk_container_remove() on it is the way you > are supposed to take a widget from a container. Removing a widget from > its container will decrease the refcount of the widget to 0 and thus > destroy it (unless reffed by someone else of course). Now, it _should_ > work both ways, but I think the expected method is worth the trouble > to at least test whether it fixes the bug (no high hopes for that to > happen though, since removing from the container is a part of the > destruction process. But you never know! ;).
In the real application (the GTK frontend for debian-installer) we have a toplevel window and some widgets that are never destroyed, while others get created and then deleted at every installation step. When a step is done i remove via gtk_widget_destroy() a box which holds, as children, all the widgets i no longer need, and here is where the leak happens. Your hint is somehow a workaround: gtk_container_remove() decerements ref counter and causes memory release, even if i still get a lot of warnings afterwards. In the unlucky case this bug cannot be fixed properly, then the gtk_container_remove() trick may do as a workaround. thanks Attilio In the (unlucky) case this leak cannot be properly fixed, your hint allow I tried the g_object_unref() _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
