[g-a-devel] Need ATK experienced help
- From: "Quiring, Sam" <Sam Quiring windriver com>
- To: <Gnome-accessibility-devel gnome org>
- Subject: [g-a-devel] Need ATK experienced help
- Date: Tue, 1 Sep 2009 14:21:21 -0700
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
[Date Prev][
Date Next] [Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]