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 > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
