Re: Memory management in GTK+/gail

[Marc Mulcahy <marc mulcahy sun com>]

Thanks, I'll mimmic this behavior in my stuff.  the debugger showed me 
before I saw your message that gtk_widget_get_accessible doesn't ref the 
object-- I stand corrected.

Thanks,

Marc

At 08:27 AM 11/13/2001 +0000, Padraig O'Briain wrote:
> Marc,
>
> I disagree with your description of what gtk_widget_get_accessible does. If
> there is a cached accessible, it is returned without its ref count being
> incremented. What leads you to think that the ref count is incremented?
>
> I do not regard the behavior of gail_container_ref_child as a bug. The object
> returned by this function must have its ref count incremented as it is 
> expected
> that the caller will unref it.
>
> When an accessible object is created for a widget, it should continue to 
> exist
> until the widget is destroyed. There is an unref call in gtk_widget_finalize
> which should cancel out the ref call made when the accessible object was
> created.
>
> My view is that one should not unref the object returned by
> gtk_widget_get_accessible. I regard the fact that we used get rather than 
> ref in
> the function name as a hint that the return value should not be unref'ed.
>
> I regard it as a bug to unref the AtkObject returned by
> gtk_widget_get_accessible and would expect nasty things to happen if I do an
> unref and subsequently call gtk_widget_get_accessible; I have done it to 
> myself
> a number of times by accident and one gets a core which may not seem to be
> related to the actual cause.
>
> Padraig
>
>
> > This question could be a brain-dead one, so please forgive me if it is:
> >
> > I have the accessibility implementation for libgnomecanvas reasonably
> > complete such that the GAIL testtoplevel util can dig through all the
> > children objects of the canvas and return objects implementing AtkText for
> > the GnomeCanvasRichText and GnomeCanvasText objects.  But...
> >
> > I implemented AtkObject caching in a similar way to GTK+ with
> > g_object_set/get_qdata.  But, it's horribly broken, and I'm now not sure
> > quite why it doesn't work and the implementation in GTK+/gail does.  What
> > appears to happen in gtkwidget.c:
> >
> > 1. Check to see if the gtkwidget has a pointer to a cached accessible.
> > 2. If it does, ref the accessible and return it.
> > 3. If not, instantiate the appropriate factory, create the accessible and
> > return it.
> >
> > Now... what happens when the client calls gtk_widget_get_accessible for a
> > widget, unrefs the return value, and again calls gtk_widget_get_accessible
> > for the same widget?  How does the code know that the AtkObject stored in
> > the qdata is no longer valid once the AtkObject returned by
> > gtk_widget_get_accessible is unreffed.  In the case of my code for
> > libgnomecanvas, which seems to closely mimmic the behavior for GTK 
> widgets,
> > it blows up.
> >
> > One possible, but probably wrong reason why it doesn't blow up for 
> standard
> > gtk widgets, is an apparent memory leak in gailcontainer.c.  when
> > gail_container_ref_child is called, it calls gtk_widget_get_accessible on
> > the specified child.  If the accessible for the specified child exists, it
> > is reffed and returned by gtk_widget_get_accessible.  If not, it is 
> created
> > and returned.  Either way, the ref count is either set to 1, or
> > incremented.  then upon return from gtk_widget_get_accessible, the 
> returned
> > accessible is reffed again.  So in the case of the above problem with the
> > qdata, nothing blows up since the object never goes away.
> >
> > Am I confused?  Any comments?
> >
> > Marc
> >