GNOME Bugzilla – Bug 656004
GNOME-Shell gets frozen on selection events using Orca
Last modified: 2011-08-23 16:55:18 UTC
PRECONDITIONS: at-spi2, Orca and gnome-shell from repositories a11y enabled, at-spi-bus-launcher and at-spi2-registryd running gnome-shell STEPS TO REPRODUCE 1. Start Orca 2. Press Alt+F1 to move to overview 3. Start to write to filter apps and try to move EXPECTED OUTCOME Orca speechs each app selected, as "app selected, button" ACTUAL OUTCOME Sometimes you can hear "Button selected", but the desktop gets frozen. If I kill orca, things start to work again. ADDITIONAL INFORMATION I created this bug on at-spi2-core because after triagge a little, if I remove this commit: http://git.gnome.org/browse/at-spi2-core/commit/?id=229a6039d0c7a91cee71037741173d9a94a39e77 Things work fine. For what it worth, as this at-spi2-core is related with relationset, those buttons don't have a name by their own, they have a relation with a label. So in order to get the name Orca needs to go into ATK_RELATION_LABELLED_BY and ATK_RELATION_LABEL_FOR.
Created attachment 193282 [details] at-spi2-registryd backtrace Just adding in which point is at-spi2-registryd when the app get frozen. It seems a key notification. Not sure if it has any value
(In reply to comment #1) > Created an attachment (id=193282) [details] > at-spi2-registryd backtrace > > Just adding in which point is at-spi2-registryd when the app get frozen. It > seems a key notification. Not sure if it has any value It would be good to know how to get something similar for Orca (in which line Orca gets stuck), but I'm not too used to python. Someone knows the python equivalent to "gdb /usr/bin/app -p app_process_id"?
Alex: Do you have the latest gobject-introspection and pygobject (latest == from masterish)?
(In reply to comment #3) > Alex: Do you have the latest gobject-introspection and pygobject (latest == > from masterish)? I think so, but just in case, I'm doing right now: jhbuild build pyatspi2 -afc This includes gobject-introspection and pygobject.
With the following from master (note that gnome-shell, clutter, and cogl are not there -- yet), I do not have that freeze: * atk * at-spi2-atk * at-spi2-core * gdk-pixbuf * glib * gtk+ * orca * pango * pyatspi2 * pygobject This is with Fedora 15.
(In reply to comment #4) > (In reply to comment #3) > > Alex: Do you have the latest gobject-introspection and pygobject (latest == > > from masterish)? > > I think so, but just in case, I'm doing right now: > > jhbuild build pyatspi2 -afc > > This includes gobject-introspection and pygobject. Just finished, I still have the same freeze. (In reply to comment #5) > With the following from master (note that gnome-shell, clutter, and cogl are > not there -- yet), I do not have that freeze: So how did you try to reproduce it? > * atk > * at-spi2-atk > * at-spi2-core > * gdk-pixbuf > * glib > * gtk+ > * orca > * pango > * pyatspi2 > * pygobject > > This is with Fedora 15. I'm using ubuntu oneiric
(In reply to comment #6) > So how did you try to reproduce it? Following the steps outlined in your opening report. ;-) Because I have Orca from master, at-spi2 from master, and a gnome-shell which is causing us to emit selection events. I figured it was worth a try at least. And for other things, the relation checking is not an issue. /me returns to building dependencies.
New environment: * Fedora 15 updated to Fedora 16 now that it has branched. * The following built from master: * glib, gobject-introspection, pygobject * gtk+ * atk, at-spi2-core, at-spi2-atk, pyatspi2, orca * cogl, clutter, mutter * gdk-pixbuf, gnome-menus, gjs * gnome-shell I seem to have a 'recent enough' clutter based on the toolkit thing: mapped gnome-shell to gnome-shell Looking for orca-scripts.gnome-shell.py Could not import orca-scripts.gnome-shell.py Looking for scripts.gnome-shell.py Could not import scripts.gnome-shell.py Looking for scripts.apps.gnome-shell.py Could not import scripts.apps.gnome-shell.py Looking for scripts.toolkits.gnome-shell.py Could not import scripts.toolkits.gnome-shell.py -----> mapped clutter to CALLY <----- Looking for orca-scripts.CALLY.py Could not import orca-scripts.CALLY.py Looking for scripts.CALLY.py Could not import scripts.CALLY.py Looking for scripts.apps.CALLY.py Could not import scripts.apps.CALLY.py Looking for scripts.toolkits.CALLY.py Found scripts.toolkits.CALLY.py NEW SCRIPT: gnome-shell (module=orca.scripts.toolkits.CALLY.script) And whilst I get some freakingly disturbing delays I want to get to the bottom of, we are responding to selection change events without hanging: ~~~~~~~ bla bla bla {} SPEECH OUTPUT: 'Mines panel' TOTAL PROCESSING TIME: 0.9092 ^^^^^ PROCESS OBJECT EVENT object:state-changed:selected ^^^^^ Thus I need another hint about what I am missing. (BTW, I thought the panel things were now of ROLE_BUTTON?)
(In reply to comment #8) > Thus I need another hint about what I am missing. (BTW, I thought the panel > things were now of ROLE_BUTTON?) Does your gnome-shell include this commit: http://git.gnome.org/browse/gnome-shell/commit/?id=4322a20cbecf1aa8e9aba0eafc3fecbbd71f3bd7 ?
(In reply to comment #9) > (In reply to comment #8) > > > Thus I need another hint about what I am missing. (BTW, I thought the panel > > things were now of ROLE_BUTTON?) > > Does your gnome-shell include this commit: > > http://git.gnome.org/browse/gnome-shell/commit/?id=4322a20cbecf1aa8e9aba0eafc3fecbbd71f3bd7 > > ? Yup.
Well, taking that into account, as you suggested via IRC, probably the guilty is a third-party process, running on oneiric but not on Fedora 15. But the fact is that without that commit, it works. So next steps: * Detect that process. * Check if that commit can be safer. I will ask again: > It would be good to know how to get something similar for Orca (in which line > Orca gets stuck), but I'm not too used to python. > > Someone knows the python equivalent to "gdb /usr/bin/app -p app_process_id"?
> Someone knows the python equivalent to "gdb /usr/bin/app -p app_process_id"? I would attach to the process with gdb, following the instructions at http://www.python.org/moin/DebuggingWithGdb This works better when python is built un-optimized (passing CFLAGS=-g to configure, for instance), although you might need to explicitly specify PYTHONPATH if you build Python from source to /usr/local for instance and want it to read your distro's Python packages. Python also has a "pdb" module for debugging, but gdb might work better for debugging hangs. You might also be seeing a seg fault in at-spi or pygobject--at least on my system, Orca starts using 100% of CPU time rather than aborting on a crash.
I haven't tried gnome-shell, but I can reproduce this problem when attempting to navigate around Orca's preferences window. Orca 3.1.5, at-spi2 stack 3.1.5, atk 2.1.5, all on Ubuntu oneiric. Firefox also exhibits the same behavior, firefox 6. After bisecting and reverting the same commit that Alejandro pointed to, all works ok. Ubuntu is going through a bit of glib weirdness atm too, and its bitten a few things in our desktop stack in various places, and our glib is patched. I wouldn't be surprised if this is a possible culpret.
I believe it depends on your version of pygobject, whether the old behavior or the new behavior causes a crash, as follows, based on my testing: 2.28.4: new behavior causes a crash; old behavior does not crash. 2.90.1: neither behavior causes a crash At one point, in between 2.28.4 and 2.90.1, tne old behavior was causing a crash, and the new behavior was not causing a crash. So I changed atspi_accessible_get_relation_set to return a GPtrArray rather than a GArray, since at the time I was not immediately getting a response on the pygobject bug and the crash was blocking work that Joanie was doing on supporting introspection in Orca, so the change seemed like a good work-around. However, there are similar functions in atspi-collection.c that return GArrays and that I missed, so I would like to either revert the change I committed or modify the functions in atspi-collection.c as well. I think I would prefer to do the former, since (a) it was the original API, and (b) it retains compatibility with more versions of pygobject (I think it would only cause crashes for people using some unstable versions of pygobject in between releases). However, either change would be an API break at this point, and now we are in API freeze, so I guess I would need permission from the release team to revert the change. It might really be more correct to return a GPtrArray here than a GArray, and it is impossible to tell from the typelib whether a GArray returns flat objects or pointers to objects, but it also seems preferable to minimize the number of times we break API (although afaik no one is currently using libatspi from C).
Ok, Ubuntu oneiric currently has pygobject 2.28.6, which explains Mike's comment about the version differences.
(In reply to comment #14) > I believe it depends on your version of pygobject, whether the old behavior or > the new behavior causes a crash, as follows, based on my testing: > > 2.28.4: new behavior causes a crash; old behavior does not crash. > 2.90.1: neither behavior causes a crash So, in theory, if I also compile orca on jhbuild environment, things should work, right? Although ... (In reply to comment #13) > > Ubuntu is going through a bit of glib weirdness atm too, and its bitten a few > things in our desktop stack in various places, and our glib is patched. I > wouldn't be surprised if this is a possible culpret. At this moment Oneiric is it a bit of weirdness in a lot of places, as I'm not able to start a X session, so I can't make that test for the moment.
Freezes aren't in effect yet according to Matthias, so I've reverted this change. However, it may need further consideration depending on how BGO#657120 is handled.