GNOME Bugzilla – Bug 640166
Orca may lock up when openoffice applications close
Last modified: 2012-10-05 02:07:30 UTC
Created attachment 178922 [details] Debug file showing the events I think are relevant to this problem. Sometimes when openoffice applications close orca may lock up. This may occur when openoffice crashes as in bug#635604 or sometimes when the user closes the application. I believe openoffice might be showing a dialog box at this point as some users have reported that pressing enter can enable orca to start working again. I have managed to get a debug file from orca showing this occuring on my system (I cannot confirm whether just pressing enter would have got orca going again as I switched to a text console and got orca to exit so that the problem would be at the end of the file). Also please note this debug file I have trimmed down as the original was about 3MB. In trimming the file down, what I have done is removed everything before the event which got orca to speak for the last time in openoffice before the crash occurred, I think this has preserved all relevant information. I do have the full file should more be needed. One part of the debug which caught my attention is the following: DEQUEUED WINDOW:DEACTIVATE <---------- vvvvv PROCESS OBJECT EVENT window:deactivate vvvvv OBJECT EVENT: window:deactivate detail=(0,0,Tactics in Rifle Shooting.doc - OpenOffice.org Writer) Traceback (most recent call last):
+ Trace 225631
state = event.source.getState()
raise LookupError(e) LookupError
self._processObjectEvent(event)
orca.setLocusOfFocus(event, None)
event, oldLocusOfFocus, orca_state.locusOfFocus)
details = debug.getAccessibleDetails(self.debugLevel, event.source)
app = acc.getApplication()
app = self._mix_getApplication()
DEQUEUED WINDOW:ACTIVATE <---------- Yes that event doesn't have the normal line denoting the end of processing of events, indicating this error could have left things in a very inconsistant state. Another part which caught my attention is the KeyErrors towards the end of the debug file, not sure how significant they are but I haven't really come across any of those in other orca debug files. Unfortunately I am not sure whether I have the permission to provide the document I was reading which lead to this crash, but I think other documents can cause this.
Michael, I see very similar or equals traceback error messages with an another I attached debug.out file (Orca freezing related bugreport). Look my last comment in bug 640132 The my last comment wrote informations is equals with you are seeing? Attila
I did notice your comment in the other bug report. I felt it would be better to have a separate report relating to the locking up as the other one deals with openoffice actually crashing (IE. this is to protect users in the case it happens instead of sort out the excessive crashing, even when the excessive crashing is prevented we cannot assume orca users will never encounter a crash). (In reply to comment #1) > Michael, I see very similar or equals traceback error messages with an another > I attached debug.out file (Orca freezing related bugreport). > Look my last comment in bug 640132 > The my last comment wrote informations is equals with you are seeing? > > Attila
I have done a little further looking in to this, it appears that my original suspicion was wrong. I modified my orca so that setLocusOfFocus just returns when this exception is thrown by the script (in this particular case I believe it is safe as no state is changed in orca and so the result is just like the script was not notified of the change). My suspicion is now going towards the exception in the window activated event for the dialog which appears as that has a traceback in it.
A LookupError simply means that the accessible has gone away. It's not significant; it's something we've always seen. The question is why it's an issue now -- assuming it is. Which I'm digging into.
Also, Michael if you look at the end of your debug.out, you'll see a bunch of instances where you are pressing keys but Orca is getting no events to process (see below). Under those circumstances, what happens if you Alt+Tab into another window? Or launch another application? Still nothing? KEYEVENT: type=0 id=65362 hw_code=111 modifiers=0 event_string=(Up) is_text=True timestamp=9462705 time=1295605338.328071 KEYBOARDEVENT: type=0 id=65362 hw_code=111 modifiers=0 event_string=(Up) keyval_name=(Up) is_text=True timestamp=9462705 time=1295605338.328345 orca.keyEcho: string to echo: Up orca.isModifierKey: returning: False orca.isNavigationKey: returning: True orca.isModifierKey: returning: False orca.isModifierKey: returning: False KEYEVENT: type=1 id=65362 hw_code=111 modifiers=0 event_string=(Up) is_text=True timestamp=9462880 time=1295605338.503543 KEYBOARDEVENT: type=1 id=65362 hw_code=111 modifiers=0 event_string=(Up) keyval_name=(Up) is_text=True timestamp=9462880 time=1295605338.503880 orca.isModifierKey: returning: False orca.isModifierKey: returning: False KEYEVENT: type=0 id=65364 hw_code=116 modifiers=0 event_string=(Down) is_text=True timestamp=9464629 time=1295605340.252791 KEYBOARDEVENT: type=0 id=65364 hw_code=116 modifiers=0 event_string=(Down) keyval_name=(Down) is_text=True timestamp=9464629 time=1295605340.253047 orca.keyEcho: string to echo: Down orca.isModifierKey: returning: False orca.isNavigationKey: returning: True orca.isModifierKey: returning: False orca.isModifierKey: returning: False KEYEVENT: type=1 id=65364 hw_code=116 modifiers=0 event_string=(Down) is_text=True timestamp=9464731 time=1295605340.354011 KEYBOARDEVENT: type=1 id=65364 hw_code=116 modifiers=0 event_string=(Down) keyval_name=(Down) is_text=True timestamp=9464731 time=1295605340.354301 orca.isModifierKey: returning: False orca.isModifierKey: returning: False KEYEVENT: type=0 id=65507 hw_code=37 modifiers=0 event_string=(Control_L) is_text=True timestamp=9467010 time=1295605342.635569 KEYBOARDEVENT: type=0 id=65507 hw_code=37 modifiers=0 event_string=(Control_L) keyval_name=(Control_L) is_text=True timestamp=9467010 time=1295605342.635824 orca.keyEcho: string to echo: Control_L orca.isModifierKey: returning: True orca.isModifierKey: returning: True orca.isModifierKey: returning: True KEYEVENT: type=0 id=65513 hw_code=64 modifiers=4 event_string=(Alt_L) is_text=True timestamp=9467015 time=1295605342.680206 KEYBOARDEVENT: type=0 id=65513 hw_code=64 modifiers=4 event_string=(Alt_L) keyval_name=(Alt_L) is_text=True timestamp=9467015 time=1295605342.680462 orca.keyEcho: string to echo: Alt_L orca.isModifierKey: returning: True orca.isModifierKey: returning: True orca.isModifierKey: returning: True KEYEVENT: type=1 id=65507 hw_code=37 modifiers=12 event_string=(Control_L) is_text=True timestamp=9467089 time=1295605342.738017 KEYBOARDEVENT: type=1 id=65507 hw_code=37 modifiers=12 event_string=(Control_L) keyval_name=(Control_L) is_text=True timestamp=9467089 time=1295605342.738285 orca.isModifierKey: returning: True orca.isModifierKey: returning: True KEYEVENT: type=1 id=65513 hw_code=64 modifiers=8 event_string=(Alt_L) is_text=True timestamp=9467089 time=1295605342.740823 KEYBOARDEVENT: type=1 id=65513 hw_code=64 modifiers=8 event_string=(Alt_L) keyval_name=(Alt_L) is_text=True timestamp=9467089 time=1295605342.741061 orca.isModifierKey: returning: True orca.isModifierKey: returning: True KEYEVENT: type=1 id=65470 hw_code=67 modifiers=0 event_string=(F1) is_text=True timestamp=9467089 time=1295605342.743231 KEYBOARDEVENT: type=1 id=65470 hw_code=67 modifiers=0 event_string=(F1) keyval_name=(F1) is_text=True timestamp=9467089 time=1295605342.743531
Created attachment 178954 [details] I am thinking may be not to those LookupErrors as a crash caused in another way doesn't give those errors in the orca debug.
I got mixed up with the description for the attachment, here is a better explanation. I have caused a crash of openoffice in another way, this doesn't give those LookupErrors I was suspecting as the cause to this problem. However I do think the one where the processing of the event gets cut off as seen in the way the debug file does not contain the line denoting the end of the processing of the event probably still should be corrected as it could mean important code in the core may not be run. As to the debug in the attachment. This one was done causing the crash in this other way. Also what happens if I move focus away from the error dialog, still no speech or Braille. The debug shows me moving focus away (pressing alt+f2 and giving the orca command with the -q option, twice). The reason I give the quit command twice is that orca did not seem to quit properly the first time. Also you may observe key presses for me going to a text console (ctrl+alt+f1), in those I was only reading the debug output up to that point. Hope that explains the debug in the attachment a bit better. (In reply to comment #6) > Created an attachment (id=178954) [details] > I am thinking may be not to those LookupErrors as a crash caused in another way > doesn't give those errors in the orca debug.
What caused Orca lockups is blocking that no longer happens thanks to a change in AT-SPI2 during the GNOME 3.4 cycle.