Red Hat Bugzilla – Bug 243735
XFCE stops responding to keypress/mouse button events
Last modified: 2007-11-30 17:12:07 EST
Description of problem: After running for some time, the graphics system stops processing key presses and mouse button events. Mouse cursor still tracks; sometimes ctl-alt-bs will kill X, sometimes not. Not really sure that this is a Window Manager problem Running devel version of xfce on T60 laptop (Core2-Duo). Version-Release number of selected component (if applicable): xfwm4-4.4.1-1.fc7 How reproducible: fairly reproducible, just random time until failure Steps to Reproduce: 1. Boot into rawhide Fedora kernel 2. Login to XFCE 3. Wait for keyboard/mouse buttons to stop responding Actual results: Display still active, but no response to keyboard input or mouse button presses; sometimes ctl-alt-bs will kill X. Expected results: Normal usage of XFCE Additional info: As I said, not sure that WM is actually the culprit. Switching to GNOME does not seem to trigger this, so I do think it's an XFCE issue. Next time it happens I'll try ssh'ing into the laptop to insure that the rest of the system is running (pretty sure it is).
Very odd. Sounds like something is grabbing your keyboard/mouse and not letting go. Are you running xscreensaver? I have been running here on a core2duo laptop for ages 24x7 and have never seen this.
It does sound like something has grabbed and not let go, since everything else seems to work. I finally setup sshd so that I can login to the laptop through the net, so I'll swap back to XFCE and try it again. I do have xscreensaver enabled, but this seems to happen while I'm active. I'll be typing or doing mouse things and suddenly hitting mouse button in a window's header doesn't swap focus. Is there anything I can do if I get logged in to see if something has grabbed focus? Also, are you running 32-bit or 64-bit? Clark
Yeah, not sure how to determine what process has the keyboard grabbed from remote. :( Might be some clever way with devilspie or something... Or perhaps you could start a 'xev >& /tmp/foobar' and then examine that to see what has grabbed? I am running x86_64 here.
Tried it again tonight, had a couple of terminals open, Thunderbird and pidgin running. When I lost input, I went to a different laptop, ssh'ed in to the "locked" box. Running 'top' didn't show me anything spinning out of control (didn't really expect it). Things did seem to be a trifle..."jerky", kinda like running over a slow communications channel. After a while, the ssh session stopped responding and further attempts to login failed with "no response". I may try the xev trick next.
Still very puzzled on this one. I use pidgin here just fine. The only app I don't use that you have mentioned is thunderbird. Is there nothing in your /var/log/messages, /var/log/Xorg.0.log, or ~/.xsession-errors files?
Got the same problem after updating 1-month-old rawhide to today's Waste some hours to find the problem. Tries to turn back xfce4-panel, libwnck, notification libs etc. No results. How to reproduce? Very simple. 2 facts: 1) task switching via Alt-Tab works fine 2) task switching via panel's task manager works fine But if you combine 1 and 2, xfwm hangs!!! So to reproduce just run several tasks and try to switch by alt-tab, by task manager with mouse and you will got 100% result... After a hours of having sex with fedora, just found the problem is with gtk2 libs !!! Removed by "rpm --nodeps -e `rpm -qa|grep ^gtk2`" and installed older gtk2 from fedora7 base. BAD: gtk2-2.11.3-1.fc8.i386.rpm gtk2-devel-2.11.3-1.fc8.i386.rpm gtk2-engines-2.11.1-2.fc8.i386.rpm GOOD: gtk2-engines-2.10.0-3.fc7 gtk2-devel-2.10.11-7.fc7 gtk2-2.10.11-7.fc7 Guys please inform xfce4 developers with this bug.
Ah ha. Excellent detective work. I wonder if it's just a rebuild of xfwm4 against the new gtk2 that would fix things? Would you guys be willing and able to test a rebuilt xfwm4 package? I can easily make one, or you can rpmbuild --rebuild the src.rpm and try it?
Doesn't seem to. I grabbed the xfwm4-4.4.1-1 SRPM and rebuilt it on the current rawhide (gtk2-2.11.3-1.fc8). Started up xfce and I went nuts swapping workspaces (using scroll-wheel, pager and alt-tab. After about a minute, it hung again. Just out of idle curiosity, how would I verify that xfwm4 is what hung on my box?
Just to confirm Denis' workaround, I downgraded my gtk2* as listed above and have been running fine for over an hour (because I make heavy use of workspaces, I usually lock up in a minute or two).
Filed upstream bug: http://bugzilla.xfce.org/show_bug.cgi?id=3346 For checking to make sure it's xfwm4 you could try doing a strace on it?
This is bug of combination of xfwm4 + xfce4-panel + gtk2_from_rawhide. Without panel all is ok. Strace on xfwm4 hangs on poll() Very strange bug.
glib2-2.13.4-1.fc8 is also buggy with xfce Terminal (Terminal-0.2.6-2.fc7) The problem when you opening several tabs and finish some of it by Ctrl-C, Terminal may fall to core dump... Back to glib2-2.12.11-1.fc7 solved this issue! Seems rawhide packages is tested not so enough. ;)
I had this happen on a rawhide i686 laptop this weekend, so it seems to transcend architecture. did the downgrade of gtk2* to f7 versions and it worked fine.
Well, upstream has identified the problem and has a patch. They are talking about if this is important enough to push a 4.4.2 release now. Can all of you guys who are seeing this re-upgrade your gtk2 and try the rpms from: http://www.scrye.com/~kevin/fedora/xfwm/ and report back if that fixes the issue or not?
I updated to xfwm4-4.4.1-2.fc8 from the above link and then updated to the latest gtk2, gtk2-devel and gtk2-engines and that seems to have fixed my problem. At least I've been running for an hour, switching workspaces and generally just working without the system losing mouse/keyboard events.
Excellent. Thanks for testing. I will update upstream.
ok, since it's looking like 4.4.2 is going to take somewhat longer to be released than I had hoped, I went ahead and added this patch into xfwm4 in rawhide. Package: xfwm4-4.4.1-2.fc8 Tag: dist-f8 Status: complete Built by: kevin Should be out in tomorrow's rawhide push. Feel free to re-open this or file a new bug if you spot any problems with this fix.