Re: Memory management in GTK+/gail

["Padraig O'Briain" <Padraig Obriain sun com>]

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
>