GNOME Bugzilla – Bug 400763
Orca hangs after starting the update process in update manager
Last modified: 2007-02-13 23:30:22 UTC
Steps to reproduce: 1/ open update manager 2/ select the updates you wish to perform. 3/ click "startt download". Results. the download and update process begins. Orca hangs. The update process finish. Orca is still hung. Restarting Orca restores speech and braille.
Created attachment 81271 [details] Orca debug from testing this problem. As I have no updated available to download via the update manager on my Ubuntu Feisty machine, I took a slightly different set of steps to reprocude this problem: 1/ Start the Update Manager from the Control Center 2/ Click on the Check button The Update Manager put up a dialog box saying that it's checking download information. After a few seconds, Orca says: 'User logged out - shutting down.' and then terminates.
Created attachment 81272 [details] Good Orca debug output on Edgy. File contains the debug output from Orca on Edgy, where there were no problem (should we need to compare).
The other thing to note with this bug is that we start getting COMM_FAILURE's almost immediately, and Orca continually reports: ERROR: received an event with no source.
Created attachment 81275 [details] Orca debug output for another "bad" run on Ubuntu Feisty. This time I started Orca first, then started "update-manager". No "User logged out. Shutting down" message, just a load of COMM_FAILURES. Visually I was able to see what was going on, and I navigated to the appropriate buttons to continue with the software update. Occasionally speech would come back, but for most of the update, it was silent. This run is probably closer to what Mike was seeing.
Helps to add the comment to the right bug. Well it looks like I shouldn't have done that last python-dbus update. The update-manager just crashes every time now (even after a reboot). GTK Accessibility Module initialized Traceback (most recent call last):
+ Trace 105488
app = UpdateManager(data_dir)
self.setupDbus()
'/org/freedesktop/UpdateManagerObject')
follow_name_owner_changes=follow_name_owner_changes)
_dbus_bindings.UInt32(0))
reply_message = self._connection.send_message_with_reply_and_block(message, timeout)
org.freedesktop.UpdateManager was not provided by any .service files
Created attachment 81472 [details] [review] Patch to improve the situation. Will and I looked at this further and discussed it this morning. The problem is that Orca is getting a sequence of accessibility events for those little dialogs that update-manager likes to throw up on the screen. Orca is synchronously queueing them, and then (at a later point) asynchronous processing them. What's happening is that some of those dialogs are short lived. In other words, Orca is getting "window:deactivate" and "window:destroy" events for a dialog, which invalidates that dialog (and the objects underneath it). Orca was then coming along and trying to process the previously queued events for objects that no longer exist. I added a line to print out the stack for the various COMM_FAILURES, (in the except: clause at line 674 in atspi.py). This stack looks like:
+ Trace 106394
start(registry) # waits until we stop the registry
registry.start()
bonobo.main()
self._processObjectEvent(event)
and event.source.state.count(atspi.Accessibility.STATE_DEFUNCT):
return self.__get_state()
stateSet = self.accessible.getState()
self.callback(event)
event = atspi.Event(e)
self.source = Accessible.makeAccessible(e.source)
obj = Accessible(acc)
debug.printStack(debug.LEVEL_SEVERE)
traceback.print_stack(None, 100, debugFile)
is currently implemented. It would be nice if we were able to get a handle to the accessible object that those previous queued events were for even after the "window:deactivate" and "window:destroy" events have come in. Comments...
Created attachment 81473 [details] Orca debug output for an update-manager run with the patch installed. You'll need to use gunzip to decompress this debug file.
I don't know if the following is an indication that the problem is more general or if it's a complete coincidence/new bug. But given all the COMM_FAILURES, I decided to start here. :-) As of today, on both my Feisty boxes, I occasionally* get the following when I attempt to quit Orca with Insert Q having started it from a gnome-terminal window: Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x861a0d4>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x861a10c>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d379c>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d37d4>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d380c>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3d14>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3844>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d387c>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d38b4>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d38ec>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3924>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d395c>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3994>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d39cc>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3a04>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3a3c>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3a74>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3aac>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3ae4>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3b1c>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3b54>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3b8c>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3bc4>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3bfc>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3c34>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3c6c>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3ca4>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3cdc>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3d4c>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3d84>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3dbc>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3df4>> ignored Exception CORBA.COMM_FAILURE: COMM_FAILURE() in <bound method EventListener.__del__ of <orca.atspi.EventListener object at 0x86d3e2c>> ignored * occasionally = maybe 1 out of every 10 times, and that's actively trying to make the bug occur. Note: To eliminate the possibility of this being a side effect of Bill's patch for bug #400709, I reverted to the current at-spi package for Feisty. Doesn't seem to make a difference.
Hi Rich, this patch does seem to improve the problem. I've been running with the patch for quite a while now and have yet to see any serius side effects.
Thanks Mike. I've committed the patch. Will and I discussed this bug this morning. He has a nice idea that needs to be investigated future after GNOME 2.18 is out the door. Namely, instead of calling "Accessible.deleteAccessible(e.source)" in _onStateChanged() in atspi.py, we should set the e.source.valid to False. Then when we process the events asynchronously at a later point, we should look for "object:state-changed:defunct" events and call "Accessible.deleteAccessible(e.source)" at that point.
I'd also feel more comfortable if there were some testing with the Java platform before/after the patch. The sole reason we put a lot of the COMM_FAILURE handling code in Orca was to deal with intermittent connectivity problems we ran into while talking to a running Java application. I'm don't recall if the ref() was the source of the issues, but it would be a good thing to try to run SwingSet and the sample text editor application that comes with the JDK. See if the behavior is the same before/after the patch.
Created attachment 81773 [details] Orca debug.out when testing Java SwingSet2 with patch applied (i.e. latest Orca in svn trunk/HEAD).
Created attachment 81775 [details] Orca debug.out when testing SwingSet2 with a version of Orca with the patch removed. What we are getting here (for both test runs), is that it's not recognizing KEYEVENTS (let alone outputting speech and braille), when focus is in the Java application window. The test I actually did was to Tab around along the graphical icon bar and then press F10 to get focus on the menu bar, and walk down the File menu finally selecting the "Exit" menu item. This is with java-1.5.0-sun-1.5.0.08. Ran the SwingSet2 with: % /usr/lib/jvm/java-1.5.0-sun-1.5.0.08/demo/jfc/SwingSet2 % /usr/lib/jvm/java-1.5.0-sun-1.5.0.08/bin/java -jar SwingSet2.jar from a gnome-terminal window. Are others seeing the same problem? Should I file a separate bug on this?
Did you set the Java access bridge up (http://live.gnome.org/Orca/JABG)? It looks like you're not getting anything at all from the SwingSet app.
D'oh! No I didn't. I'll work on that now. Thanks.
As reported offline, I've been unable to successfully build the Java Access Bridge (JAB) per the instructions on http://live.gnome.org/Orca/JABG. Lynn has kindly offered to run the SwingSet2 demo with the JAB and latest Orca, and will test this patch. to make sure that there are no regressions w.r.t. Java support. Lynn, please report your finding here. Thanks.
Hi Rich, I've run the latest Orca with SwingSet2 and didn't see any obvious problems during a very quick test. Is there anything specific you want me to test?
Perhaps it would be appropriate to attach a debug.out for such a test. Uncomment: orca.debug.debugLevel = orca.debug.LEVEL_ALL orca.debug.eventDebugLevel = orca.debug.LEVEL_OFF in your ~/.orca/user-settings.py file to get full debug output. We are looking to see if there are any inappropriate: "IGNORING INVALID EVENT ..." lines being generated.
Created attachment 82492 [details] debug.out for SwingSet2
Created attachment 82493 [details] debug.out for jedit
I ran SwingSet2, then jedit with the latest orca. Speech and braille displayed was good, except for text in jedit. No text was spoken. Grepping for "IGNORING" in debug.out yielded many "IGNORING DEFUNCT OBJECT" lines. This makes sense since I was getting bogus COMM_FAILURE retry warning message on the terminal running SwingSet2 and jedit. Once again, these COMM_FAILURE stack traces are just warning messages from CORBA that a request or response needed to be retransmitted. The bug in CORBA is that these retries are normal, and a warning should not be displayed. It's roughly the equivalent of accidently leaving the debug level as debug.LEVEL_SEVERE in a module that was checked in.
Addendum to Comment #21. Grepping for "IGNORING" yielded *only* "IGNORING DEFUNCT OBJECT" lines. The CORBA COMM_FAILURE warnings probably causes orca to ignore events from object that it believes are defunct.
Thanks Lynn. Will, I think it should be okay to close this one out now. Do you agree?
(In reply to comment #23) > Thanks Lynn. > > Will, I think it should be okay to close this one out now. > Do you agree? Thanks Lynn! I'm a bit nervous about the part where Lynn says "Speech and braille displayed was good, except for text in jedit. No text was spoken." I say close this bug (bug 400763) out as fixed and file a new one for the jedit issue. It looks like the jedit issue is a separate problem. Lynn, can you file that bug please (and assign it to yourself :-))?
Doing my bit. 8-) Closing this one as FIXED.