Memory management in GTK+/gail

[Marc Mulcahy <marc mulcahy sun com>]

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