GNOME Bugzilla – Bug 666371
Several object-reference warnings while activating the accessibility support
Last modified: 2012-01-21 18:19:17 UTC
STEPS TO REPRODUCE IT: 1. Run gnome-shell (ie: gnome-shell --replace) 2. Go to Universal Access Menu and activate Screen Reader 3. Take a look to output messages FREQUENCY: Most of the times it doesn't happen the first time you open Orca, so probably you will require to deactivate it and run 2. again DEBUG OUTPUT: <snip> Window manager warning: Log level 8: g_object_ref: assertion `G_IS_OBJECT (object)' failed Window manager warning: Log level 8: g_object_ref: assertion `G_IS_OBJECT (object)' failed Window manager warning: Log level 8: g_object_ref: assertion `G_IS_OBJECT (object)' failed Window manager warning: Log level 8: g_object_ref: assertion `G_IS_OBJECT (object)' failed Window manager warning: Log level 16: invalid uninstantiatable type `(null)' in cast to `GObject' Window manager warning: Log level 8: g_object_ref: assertion `G_IS_OBJECT (object)' failed Window manager warning: Log level 16: invalid uninstantiatable type `(null)' in cast to `GObject' Window manager warning: Log level 8: g_object_get_data: assertion `G_IS_OBJECT (object)' failed Window manager warning: Log level 8: register_object: assertion `G_IS_OBJECT (gobj)' failed Window manager warning: Log level 8: g_object_get_data: assertion `G_IS_OBJECT (object)' failed Window manager warning: Log level 16: invalid uninstantiatable type `(null)' in cast to `GObject' Window manager warning: Log level 8: g_object_ref: assertion `G_IS_OBJECT (object)' failed Window manager warning: Log level 16: invalid uninstantiatable type `(null)' in cast to `GObject' Window manager warning: Log level 8: g_object_get_data: assertion `G_IS_OBJECT (object)' failed Window manager warning: Log level 8: register_object: assertion `G_IS_OBJECT (gobj)' failed Window manager warning: Log level 8: g_object_get_data: assertion `G_IS_OBJECT (object)' failed Window manager warning: Log level 16: invalid uninstantiatable type `(null)' in cast to `GObject' Window manager warning: Log level 8: g_object_ref: assertion `G_IS_OBJECT (object)' failed Window manager warning: Log level 16: invalid uninstantiatable type `(null)' in cast to `GObject' </snip> NOTES: At first my plan was open this bug on GNOME Shell, but Joanmarie mentioned that something similar happens (with some crashes) on epiphany/webkitgtk, so I have just created this on this shared component. It needs further investigation, we can move to the proper component later.
Not sure if it's relevant to you or not, but every time launching Orca causes a crash, the following seems to be the case: 1. We have a whole bunch of events from objects with STATE_DEFUNCT 2. This is followed by an event from a supposedly valid object: * object:state-changed:showing (detail1 == 0) * role == UNKNOWN * states: FOCUSABLE and VISIBLE (and *not* DEFUNCT) At this point, gnome-shell crashes and restarts itself. There is no hang, and Orca survives the entire thing.
And where things seem to be going south in particular -- at least as far as Orca is concerned -- is here:
+ Trace 229316
Atspi.Accessible.name = property(fget=lambda x: exwrap(Atspi.Accessible.get_name, x))
raise LookupError
Thanks for the additional comments. (In reply to comment #1) > Not sure if it's relevant to you or not, but every time launching Orca causes a > crash, the following seems to be the case: > > 1. We have a whole bunch of events from objects with STATE_DEFUNCT > 2. This is followed by an event from a supposedly valid object: > * object:state-changed:showing (detail1 == 0) Just while we were talking via IRC, I was checking where this showing is emitted but ... > * role == UNKNOWN > * states: FOCUSABLE and VISIBLE (and *not* DEFUNCT) ... this was a ATK_STATE_DEFUNCT check, so probably this will not be useful. Anyway, FWIW, Im not able to crash GNOME Shell with Orca using any specific steps. It happens sometimes. Do you have a "recipe" to get GNOME Shell crashing? I will keep investigating this.
(Sorry to be spammy!) Now that I'm running with gnome-shell --replace, when I launch Orca and gnome-shell dies in response, I am seeing this quite a bit: gnome-shell-calendar-server[29420]: Got HUP on stdin - exiting Not sure exactly what I or Orca might be doing to upset the calendar-server. <shrugs> Also please note that this, along with the earlier comments, pertain to Fedora 16, with Orca, AT-SPI2, and ATK from master. I am in the midst of a refactor at the moment. I'll update my Fedora 17/rawhide box and test more thoroughly later. (Mid-air collision!) (In reply to comment #3) > Anyway, FWIW, Im not able to crash GNOME Shell with Orca using any specific > steps. It happens sometimes. Do you have a "recipe" to get GNOME Shell > crashing? Not yet. Sorry! But in a bit I might see if I can stop the crash itself in Orca. i.e. if I can predict what is going to p*ss off gnome-shell I can add preventive code to Orca and point out what made gnome-shell decide to stop killing itself. Maybe from that we can derive a "recipe". > I will keep investigating this. Awesomesauce! Thanks!!
During one of those crashes, I was able to get this backtrace from gnome-shell: (gdb) bt
+ Trace 229332
So it seems that it is happening on the bridge. Of course it still can be happening due a wrong ref/unref on cally code.
I also detected one warning that I didn't found on the description: Window manager warning: Log level 8: atk_gobject_accessible_dispose: assertion `ATK_IS_GOBJECT_ACCESSIBLE (data)' failed
This is with at-spi2-atk 2.3.3 (or head), right? I guess spi_global_cache is holding a pointer to an object in the hash table after the object has been finalized. In theory this should never happen since all objects in the cache are supposed to have a weak ref that removes them from the cache.
(In reply to comment #7) > This is with at-spi2-atk 2.3.3 (or head), right? I guess spi_global_cache is Test done on Comment 5 was done with Ubuntu package 2.2.1-0ubuntu. I have tested again with at-spi2 from head, and although I didn't get the crash I was able to get a backtrace on the point at those warning messages at comment 0. So, that "g_object_ref: assertion `G_IS_OBJECT (object)' failed": (gdb) bt
+ Trace 229335
The two first backtraces happens in the same method that caused a crash on comment 5. As I said, those backtraces are for the warnings, but didn't cause a crash. Anyway, it seems that the problem is the same, try to use an accessible that was destroyed. > holding a pointer to an object in the hash table after the object has been > finalized. In theory this should never happen since all objects in the cache > are supposed to have a weak ref that removes them from the cache. Hmm, this is odd. At first I thought that the problem was a missing _ref, or a extra _unref. But taking into account this paragraph, if this would be the case, I shouldn't have this problem as the objects should be removed by the cache before being accessed again, right? BTW, as I said in the description, this doesn't happen since the beginning. My environment is the next one: 1. Launch gnome-shell => no orca running 2. Launch orca, interact a little with gnome-shell => no warnings 3. Close orca 4. Open orca => warnings Probably when I close orca, the accessible objects are destroyed. What I don't understand is why the bridge tries to interact again with them. Additional question: should I try to disconnect the cache to test those messsages ?
(In reply to comment #8) > Probably when I close orca, the accessible objects are destroyed. What I don't > understand is why the bridge tries to interact again with them. I made an additional test. Normally the widgets doesn't maintain a reference to the accessible, as usually the accessible lives longer that the base object. This "I need to close orca and run it again" let me to think that the problem could be that the accessible object is unref, but the base object still maintains a pointer to the old accessible object. So I just tested to add a reference to the accessible object, and an unref on the base object (the widget) dispose. No luck. And, just one more backtrace of the messages at description. That gobject_get_data (gdb) bt
+ Trace 229336
I think that 85af8a in at-spi2-atk will fix this. Please re-open if you see it again.