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

["Mike Emmel" <mike emmel gmail com>]

Okay I know about this a bit.

Obviously a logic error exists and I've not figured out the right answer yet.

The reason Destroy is commented out is we should never need  to call
it on the gdk side.

The problem was related to the need to keep the DirectFB window alive
long enough to
clear out the event queue on the DFB side.

Sorry I don't have any answers for this but I'm aware of the problem.

What should happen is that the DirectFB window should probably hold a
reference to the
Gdk window and destroy it so we should start destruction of the
DFBWindow when the gdk
reference hits one.

Thats the route I was considering taking. Feel free to email me
directly with suggestion.
I don't know the best way to handle multiple ref counting schemes but
I felt that allowing the
"deepest" to bubble up might be the best route since this would clear
the event queue.

mike emmel gmail com






On 12/18/06, Attilio Fiandrotti <attilio fiandrotti gmail com> wrote:
> Loïc Minier wrote:
> > On Mon, Dec 18, 2006, Attilio Fiandrotti wrote:
> >
> >>so, i guess this patch only tackles the issue but does not properly.
> >
> >
> >  Attilio, did you notice the following block near the end of
> >  _gdk_windowing_window_destroy which your patch touches:
> > #if 0 /* let the finalizer kill it */
> >   if (!recursing && !foreign_destroy)
> >     {
> >                 if (impl->window)
> >                 impl->window->Destroy (impl->window);
> >                 impl->window = NULL;
> >         }
> > #endif
> >
> >  There's no other call to Destroy() in this file, so perhaps the
> >  Destroy() call is never made.  Could you try without the #if 0 instead
> >  of your patch?
>
> That was the first thing i tried, but i got a crash :(
>
> >  Also, did you valgrind your test case?  It should immediately point at
> >  the place where memory is leaked from I suppose.
>
> I suspect we're not actually leaking (in the sense of not freeing
> something), but rather not unreferencing something somewhere after
> disallocation: i really hope mike or sven can fix this :)
>
> cheers
>
> Attilio
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list