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

Kalle Vahlman wrote:
2006/12/18, 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 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.



In the (unlucky) case this leak cannot be properly fixed, your hint allow

I tried the g_object_unref()

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