Re: [g-a-devel] Need ATK experienced help

[Li Yuan <Li Yuan Sun COM>]

Hi Quiring,

How did you implement ref_child function? Is there a cache?

Li

On Tue, 2009-09-01 at 14:21 -0700, Quiring, Sam wrote:
> Greetings,
>  
> I'm adding ATK support to a Python platform that implements its own
> graphics library from scratch.  I'm using Papi, which has been really
> excellent.
>  
> I've just finished implementing some of the ATK support.  ATK objects
> (actually, papi.atk.AtkObject's) are created on demand.  When an
> ATK request comes in for the Nth child of an ATK node (via the ATK
> callback AtkObjectClass.ref_child), I examine the associated GUI
> node's children, find the Nth one, and create a corresponding ATK node
> for it, which I pass back to the caller.
>  
> One client I'm using to test this is an AT-SPI dump program I wrote a
> while ago.  It dumps the entire AT-SPI tree to a file.
>  
> Here's my problem:
>  
> I bring up the Python platform with the initial screen GUI.  I run my
> AT-SPI dump client program.  The dump is beautiful.  I run it again.
> The Python ATK support crashes with errors in the Python log like
> this:
>  
> ** (process:2857): CRITICAL **: get_atkobject_from_servant: assertion
> `ATK_IS_OBJECT(object->gobj)' failed
> ** (process:2857): CRITICAL **:
> impl_accessibility_accessible_get_name: assertion `object != NULL'
> failed
> ** (process:2857): CRITICAL **: get_atkobject_from_servant: assertion
> `ATK_IS_OBJECT(object->gobj)' failed
> ** (process:2857): CRITICAL **:
> impl_accessibility_accessible_get_description: assertion `object !=
> NULL' failed
> ** (process:2857): CRITICAL **: get_atkobject_from_servant: assertion
> `ATK_IS_OBJECT(object->gobj)' failed
> 
> The first time I run the client, my ATK Python support is building the
> ATK nodes on demand.  Those nodes are saved and the second time I run
> the client all the ATK nodes should exist.  And they do.  But
> somewhere in between, the first 12 bytes of memory in some of the ATK
> nodes is getting trashed.  In this case I'm talking about the real ATK
> node, the one pointed to by the papi.atk.AtkObject.
>  
> Here are some odd facts:
>  
> I wrote a routine in Python to run though the entire
> papi.atk.AtkObject tree and dump each node and it's parent (parent
> obtained via ATK call). I dumped the tree before and after the memory
> got trashed. In the before dump, every node's parent displays.  In the
> after dump, the leaf nodes cannot find their parent as a result of
> memory being trashed.  But interior nodes are ok.
>  
> To make ATK do stuff, my Python program must call a Papi routine
> (papi.atk.iterate()) over and over in the main GUI loop.  I put some
> checking code around this call examining one particular node which I
> knew would get trashed.  Before one iteration step the node is fine,
> afterwards, the node is trashed.  Is there any way I can figure out
> what action was performed by that iteration step?
>  
> Does this describe a situation familiar to anyone?  It has some
> symptoms of garbage collection, as if the leaf ATK nodes don't have
> the proper ref count.  But the "fact" that the memory seems to be
> trashed by an iteration of ATK main loop doesn't seem consistent with
> garbage collection.
>  
> Any suggestions would be appreciated.
>  
> -Sam
>  
>  
>  
>  
>  
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel