GNOME Bugzilla – Bug 344192
Orca doesn't report on "Application has unexpected crashed" dialogs.
Last modified: 2008-07-22 19:13:20 UTC
See Evolution bug #344190 for a way to reliably currently crash Evolution. At that time, a dialog appears saying that the application has crashed and offers you choices of whether you'd like to "Restart application" or "Close". Orca doesn't recognize this dialog, so doesn't speak or braille it, and a blind user it left not knowing what is going on.
Just a little more information on this. I did some experimenting and digging. The error dialog that says the application has crashed seems to run as a separate process (gnome_segv). If I run this separately from the command line as so: /usr/lib/libgnomeui-0/gnome_segv2 Blah 11 Orca can access the dialog. When I look at the debug logs from when the real crash occurs, it looks like Orca may not be getting any more AT-SPI events from Evolution when the crash occurs, so it cannot access this window. :-( This is not good. Some Google'ing leads to this: http://www.wlug.org.nz/gnome_segv(1) This leads to the following potential workaround to help prevent this dialog box from appearing: export GNOME_DISABLE_CRASH_DIALOG=1 Of course, it doesn't fix bug 344190, but it at least helps elminate some confusion.
Note that the recent "watchdog" changes to the Orca script are not useful in this situation. Orca is still running and able to do wget responses just fine. In fact, you can hit Tab to move about the gnome_segv dialog, and if you've got key echo on you'll hear "Tab" spoken. Orca is not reading anything useful from the gnome_segv dialog itself.
Thanks Will, I'll have a look at it.
Created attachment 73595 [details] Source for a simple program that easily crashes. Instructions to follow.
Created attachment 73596 [details] Orca debug generated whilst running the testprog.
I've attached a small C program that can be used to easily recreate this problem. Compile it with the gcc command in the comment at the start of testprog.c. To force a crash simply start the program and then click the "Crash Me!" button. The attached debug.out was generated when doing this. You will see that we get COMM_FAILURE's because of the crash. With key echo on, and moving around by pressing Tab causes those keystrokes to be spoken, but we get no feedback from the gnome_segv2 error dialog when it is showing. prstat shows a separate process for gnome_segv2 running when the crash dialog is being displayed: 7409 richb 50M 13M sleep 40 0 0:00:00 2.4% gnome_segv2/1 It's owned by me, so we don't appear to be seeing the gksu problem (bug #347124), but it does have similarities with the gnome-keyring-ask problem (bug #351569).
Created attachment 73647 [details] Orca trace output (gzipped) while reproducing this problem. Notes on the trace file for bug #344192: * Removed everything before the "SPEECH" line for the "Crash Me!" button and everything after the key press event for Insert (in Insert-q). * The key press event for the Return for the "Crash Me!" button is at line 2293. * The SPEECH line for the key echo of the Return press is at line 2451. * The BRAILLE LINE: 'gnome_segv2 Application Error Alert' is at line 31022. * The key press event for the Tab to move to the Close button on the gnome_segv2 dialog is at line 31732. * The SPEECH line for the key echo of the Tab press is at line 31890. So for some reason there was no speech output for the gnome_segv3 dialog between line 2451 and 31022.
Some more notes on the trace file: * We get a reference to the first event for gnome_segv2 at line 21995. * The NEW SCRIPT: line for "gnome_segv2 (module=orca.default)" is at line 23440. * There are no more references to "TRACE orca.speech..." until line 31753, *after* the user has pressed the Tab key. So something is going awry somewhere between the NEW SCRIPT line at line 23440 and the BRAILLE LINE line at 31022, because it should be speaking an announcement of this new dialog. Still looking...
Created attachment 73670 [details] New Orca debug file (with annotated commented). With help from Will (many thanks), here's what's going on. With reference to the new debug.out that I've just attached. (Note that I added some print statements to tell us when we are entering the atpsi.__get_parent() and default.findCommonAncestor() routines). * User has started up the small testprog application. * At line 2520 is the Return key pressed event for the "Crash me!" button. * At line 2596 is the "NEW SCRIPT: gnome_segv2 (module=orca.default)" line because the gnome_segv2 application has started up and received an event. * At line 2789 is the "BRAILLE LINE: 'gnome_segv2 Application Error Alert'" line, as a result of calling: self.updateBraille(newLocusOfFocus) at line 1255 in locusOfFocusChanged() in default.py * What should happen after that is we should speak the new locus of focus. Instead what is happening is when we are calling: commonAncestor = self.findCommonAncestor(oldLocusOfFocus, newLocusOfFocus) at line 1262 in locusOfFocusChanged() in default.py, that routine is not imediately returning (line 2793 in debug.out). More specifically, findCommonAncestor is calling __get_parent() in atspi.py and this is hanging on the accParent = self.accessible.parent at line 872. (This was determined from the previous trace.out file at line 31717). * Now if I Tab to the Close button on the gnome_segv2 dialog (line 2794), we get a load of COMM_FAILURES. The first one confirms exactly where we were first hung: Traceback (most recent call last):
+ Trace 73602
while parent and (parent.parent != parent):
return self.__get_parent()
accParent = self.accessible.parent COMM_FAILURE
* Note that after this, there are several more COMM_FAILURES but these seem to return immediately. I don't know yet what the difference here is, between that first one and subsequent ones. ---- That's the problem. At the moment, I have no idea how to resolve it (or handle it better).
Created attachment 73731 [details] [review] Patch to hopefully fix the problem. Added in a new gnome_segv2.py script and overrode the locusOfFocusChanged() method. If the gnome_segv2 application is running it's probably because some application has crashed unexpectedly. If we just called locusOfFocusChanged() in default.py we would hang. To circumvent this, we set the old locus of focus to None, then we can safely call the locusOfFocusChanged() method in default.py.
This fix seems to work nicely with my small "Crash me!" example application. I haven't tested it extensively though. I've checked the changes into CVS HEAD and closed it as FIXED. If you see a case where this doesn't do the right thing, please feel free to just reopen the bug and I'll investigate further.