GNOME Bugzilla – Bug 561548
Orca locks up when closing some Pidgin conversations
Last modified: 2009-01-21 23:01:48 UTC
Please describe the problem: Sometimes when a Pidgin conversation closes, Orca locks up and becomes unresponsive. Furthermore, it seems to drag the entire desktop with it. If, for instance, I press alt-f2 with the intention of restarting Orca, I'd expect to hear a beep when I backspace as is normal. I don't. The only solution seems to be switching to another console and restarting Orca. Oddly, as per advice on the Orca mailing list, right-clicking the mouse seems to fix this (other clicks might work, I've just tried right.) Unfortunately there is no mouse on my desktop, so I've only been able to use this on the Eee. Steps to reproduce: 1. 2. 3. 1. Open a Pidgin conversation. 2. Close it. Actual results: Sometimes the desktop locks and becomes unresponsive. Expected results: The conversation closes and the desktop responds. Does this happen every time? No Other information: Here is a snippet of debug output. It begins with me pressing ctrl-w and continues, with me trying to alt-tab away from the locked window and, eventually, switching to a console and running orca -q. Doesn't seem like the attempts to alt-tab even appear as captured events. KEYEVENT: type=0 hw_code=105 modifiers=0 event_string=(Control_R) is_text=True time=1227113033.227159 orca.keyEcho: string to echo: Control_R orca.isModifierKey: returning: True orca.isModifierKey: returning: True orca.isModifierKey: returning: True KEYEVENT: type=0 hw_code=25 modifiers=4 event_string=() is_text=False time=1227113033.371222 orca.keyEcho: string to echo: W orca.isModifierKey: returning: False orca.isNavigationKey: returning: False orca.isPrintableKey: returning: True orca.keyEcho: speaking: W orca.isModifierKey: returning: False orca.isModifierKey: returning: False ---------> QUEUEING EVENT object:text-changed:delete ---------> QUEUEING EVENT object:property-change:accessible-name ---------> QUEUEING EVENT object:text-changed:insert DEQUEUED EVENT object:text-changed:delete <---------- vvvvv PROCESS OBJECT EVENT object:text-changed:delete vvvvv OBJECT EVENT: object:text-changed:delete detail=(0,0) ---------> QUEUEING EVENT object:property-change:accessible-name ---------> QUEUEING EVENT object:text-changed:delete ---------> QUEUEING EVENT object:property-change:accessible-name ---------> QUEUEING EVENT object:text-changed:insert ---------> QUEUEING EVENT object:property-change:accessible-name ---------> QUEUEING EVENT object:state-changed:focused app.name='pidgin' name='None' role='table cell' state='enabled focusable focused selectable sensitive single line stale transient visible' relations='' ---------> QUEUEING EVENT object:state-changed:showing ---------> QUEUEING EVENT window:deactivate ^^^^^ PROCESS OBJECT EVENT object:text-changed:delete ^^^^^ DEQUEUED EVENT object:property-change:accessible-name <---------- vvvvv PROCESS OBJECT EVENT object:property-change:accessible-name vvvvv OBJECT EVENT: object:property-change:accessible-name detail=(0,0) app.name='pidgin' name='None' role='table cell' state='enabled focusable focused selectable sensitive single line stale transient visible' relations='' ^^^^^ PROCESS OBJECT EVENT object:property-change:accessible-name ^^^^^ DEQUEUED EVENT object:text-changed:insert <---------- vvvvv PROCESS OBJECT EVENT object:text-changed:insert vvvvv OBJECT EVENT: object:text-changed:insert detail=(0,0) app.name='pidgin' name='None' role='table cell' state='enabled focusable focused selectable sensitive single line stale transient visible' relations='' ^^^^^ PROCESS OBJECT EVENT object:text-changed:insert ^^^^^ DEQUEUED EVENT object:property-change:accessible-name <---------- vvvvv PROCESS OBJECT EVENT object:property-change:accessible-name vvvvv OBJECT EVENT: object:property-change:accessible-name detail=(0,0) app.name='pidgin' name='None' role='table cell' state='enabled focusable focused selectable sensitive single line stale transient visible' relations='' ^^^^^ PROCESS OBJECT EVENT object:property-change:accessible-name ^^^^^ DEQUEUED EVENT object:text-changed:delete <---------- vvvvv PROCESS OBJECT EVENT object:text-changed:delete vvvvv OBJECT EVENT: object:text-changed:delete detail=(0,0) app.name='pidgin' name='None' role='table cell' state='enabled focusable selectable sensitive showing single line stale transient visible' relations='' ^^^^^ PROCESS OBJECT EVENT object:text-changed:delete ^^^^^ DEQUEUED EVENT object:property-change:accessible-name <---------- vvvvv PROCESS OBJECT EVENT object:property-change:accessible-name vvvvv OBJECT EVENT: object:property-change:accessible-name detail=(0,0) app.name='pidgin' name='None' role='table cell' state='enabled focusable selectable sensitive showing single line stale transient visible' relations='' ^^^^^ PROCESS OBJECT EVENT object:property-change:accessible-name ^^^^^ DEQUEUED EVENT object:text-changed:insert <---------- vvvvv PROCESS OBJECT EVENT object:text-changed:insert vvvvv OBJECT EVENT: object:text-changed:insert detail=(0,0) app.name='pidgin' name='None' role='table cell' state='enabled focusable selectable sensitive showing single line stale transient visible' relations='' ^^^^^ PROCESS OBJECT EVENT object:text-changed:insert ^^^^^ DEQUEUED EVENT object:property-change:accessible-name <---------- vvvvv PROCESS OBJECT EVENT object:property-change:accessible-name vvvvv OBJECT EVENT: object:property-change:accessible-name detail=(0,0) app.name='pidgin' name='None' role='table cell' state='enabled focusable selectable sensitive showing single line stale transient visible' relations='' ^^^^^ PROCESS OBJECT EVENT object:property-change:accessible-name ^^^^^ DEQUEUED EVENT object:state-changed:focused <---------- vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv OBJECT EVENT: object:state-changed:focused detail=(0,0) app.name='pidgin' name='None' role='text' state='editable enabled focusable focused multi line sensitive visible' relations='' Finding top-level object for source.name= --> obj.name= --> obj.name= onStateChanged: could not get frame of focused item ^^^^^ PROCESS OBJECT EVENT object:state-changed:focused ^^^^^ DEQUEUED EVENT object:state-changed:showing <---------- vvvvv PROCESS OBJECT EVENT object:state-changed:showing vvvvv OBJECT EVENT: object:state-changed:showing detail=(0,0) IGNORING DEFUNCT OBJECT ^^^^^ PROCESS OBJECT EVENT object:state-changed:showing ^^^^^ DEQUEUED EVENT window:deactivate <---------- vvvvv PROCESS OBJECT EVENT window:deactivate vvvvv OBJECT EVENT: window:deactivate detail=(0,0) IGNORING DEFUNCT OBJECT ^^^^^ PROCESS OBJECT EVENT window:deactivate ^^^^^
Hmmm...I cannot reproduce this. I'm curious -- what other applications are you running on the desktop? I've noticed that some applications, such as GNU Emacs, wreak havoc with the AT-SPI infrastructure and cause the desktop to lock up.
When it happened again last night, I had gnome-terminal, firefox, thunderbird, transmission and gedit open. And, of course, pidgin. :)
(In reply to comment #2) > When it happened again last night, I had gnome-terminal, firefox, thunderbird, > transmission and gedit open. And, of course, pidgin. :) It might be transmission. If possible, try not using that for a while and see if the problem crops back up.
I just had this happen with only pidgin open, plus whatever Ubuntu starts automatically. This happened immediately after a restart. I pretty much just launched pidgin, shut down a couple conversation windows and Orca blocked the desktop. I say Orca did it because I couldn't launch a terminal, alt-tab or the run dialog until I killed the Orca process from a console, at which point the desktop became responsive again and I could restart Orca. I've attached a log of the entire run from start to finish. Note that after I closed the last conversation window, I pressed several keystrokes which don't appear to have registered in the log. It's as if something in Orca or the accessibility infrastructure locks everything up solid. Also, I'm not sure if this makes a difference. I have Pidgin set to log into Freenode. I'm closing conversation windows on startup because Freenode opens two tabs on connect--one for its CTCP messages and another from nickserv. I'm wondering if perhaps something in that might shed a clue, though I'm not sure how. Maybe it's something in the interaction of killing two tabs in relatively quick succession. *shrug* I'm also sure I've seen one other report of this on the mailing list a month or two back, so unfortunately it isn't just me. Let me know if there's anything else I might do. It's reliably reproduceable here enough that I generally try to keep one conversation window open at all times, so I'm sure I can make it happen again.
Created attachment 124390 [details] Entire debug log of a locking session
(In reply to comment #4) > Also, I'm not sure if this makes a difference. I have Pidgin set to log into > Freenode. I'm closing conversation windows on startup because Freenode opens > two tabs on connect--one for its CTCP messages and another from nickserv. I'm > wondering if perhaps something in that might shed a clue, though I'm not sure > how. Maybe it's something in the interaction of killing two tabs in relatively > quick succession. It might be the quick closing of the windows. In addition, if you try killing pidgin instead of Orca, does the desktop come back? What I suspect is going on here is that Orca is making calls to pidgin, but pidgin isn't responding. As a result, the infrastructure would lock up. The last event in the log is certainly interesting, though: vvvvv PROCESS OBJECT EVENT object:state-changed:showing vvvvv OBJECT EVENT: object:state-changed:showing detail=(0,0) IGNORING DEFUNCT OBJECT ^^^^^ PROCESS OBJECT EVENT object:state-changed:showing ^^^^^
Haven't tried to deliberately cause this bug in Pidgin yet but I think I may have found a reliable way to replicate. This morning I installed Empathy 2.25.2 from the Ubuntu PPA. My system is stock Ubuntu with the exception of Orca trunk. With two exceptions, every window I closed in Empathy locked. Killing Empathy didn't restore Orca, and I had to run "orca -q" to get my desktop back. The exceptions were that when I closed the contacts window with escape, it closed fine. When I closed the preferences window by clicking its close button (pretty sure it had one, anyway) it closed. When I closed any other window with ctrl-w, including the contacts and conversation window, my desktop locked up. I'll see if Pidgin exhibits the same behavior later this weekend.
OK, this just happened again with Firefox 3.0.5 as shipped with Ubuntu. I've been switching from 3.1 to 3.0 fairly regularly, so the addons window appears after each switch. I closed it via escape, and the desktop locked. Killing Firefox didn't get it back, and I had to kill both FF and Orca. Here is the log from when I hit escape to close the window, until I killed Orca. Note that, once again, several keys were pressed after the lockup, and these neither register in the log nor do they trigger anything on the desktop.
Created attachment 125240 [details] Debug log of closing the Firefox addons window as it locks the desktop
Created attachment 126738 [details] [review] grasping at straws as though my very life depended on straws Nolan, I spent nearly 3 hours trying to reproduce this issue with Pidgin, with Rhythmbox (based on a comment made by someone on the list), with Firefox's add-ons dialog, with Empathy. I cannot reproduce the problem for the life of me. :-( What this patch does is implement the two things which I think might be relevant -- and invoked were it not for the defunctness of the accessible -- in on WindowDeactivated namely, setting the locusOfFocus and the activeWindow to None. I have no idea if it will make any difference because I cannot repro the issue. But we obviously need to figure this out, so I say we start with this patch. If this isn't the issue, we can cross it off our list and try again. Will, if this is lame, feel free to chime in and nix it. ;-) I'm just at a loss....
I wonder if this is the same thing as bug #567864? Nolan - does this happen to you only if/when you are flat reviewing a window and then close it? The thing that makes me suspect this is the the "Oddly, as per advice on the Orca mailing list, right-clicking the mouse seems to fix this" comment in the opener. This is the same symptom I saw when fixing bug #567864.
Created attachment 126773 [details] [review] Additional mods to potential patch Here's some additional mods to the patch to take the flat review context into account. In addition, it also catches an error condition in default.py I ran into while testing this patch (window could be None).
Obsoleting my patch. Will, your patch seems like a good, safe thing to commit whether it fixes this bug or not (although I really hope it does!). Feel funny putting a 'reviewed' status on a patch done by Will. But in the spirit of not having unreviewed patches....
Thanks Joanie! Committed to trunk. This is another we should consider for 2.24.4 after it festers for a little bit.
Before, I'd always left one pidgin conversation window open because lockups were quite common. Now I've been closing them left and right and have yet to experience a single one. I'll comment again if that changes. Thanks!
Woo hoo! :-) (Sorry for the spam, but I couldn't help it.)
Also committed to gnome-2-24 for Orca 2.24.4.
To leave it documented: This patch also solves bug #567864, at least with orca 2.24.1