Bug 13511

(In reply to comment #0)
> When some window is opened by some grabbed key, grabbing all keys and they
> destroyed (like the window ratpoison opened uppon C-t :, or the window icewm
> shows when doing Alt-Tab), the xserver is caught in an endless loop within
> PlayReleasedEvents in dix/events.c.

interesting bug... tricky to track down. 

The bug only occurs if Xkb triggers an autorepeat. In this case, XkbHandleActions overwrites dev->public.realInputProc with EnqueueEvent. When the device is unfrozen, the realInputProc is written back to the processInputProc and the whole thing craps out.

Here's a preliminary hack to fix it. It stops the loop occuring (tested with ratpoison) but I'm not sure what other implications it has. It most probably is not the correct solution.

diff --git a/include/xkbsrv.h b/include/xkbsrv.h
index 167dbec..9f7f0d6 100644
--- a/include/xkbsrv.h
+++ b/include/xkbsrv.h
@@ -258,7 +258,8 @@ typedef struct
 	    device->public.processInputProc = proc; \
 	oldprocs->processInputProc = \
 	oldprocs->realInputProc = device->public.realInputProc; \
-	device->public.realInputProc = proc; \
+        if (proc != device->public.enqueueInputProc) \
+            device->public.realInputProc = proc; \
 	oldprocs->unwrapProc = device->unwrapProc; \
 	device->unwrapProc = unwrapproc;
 

I've hit this one as well. On x86 and x86_64 laptops. It occurs when I press repeatedly volume up/down keys, kmilo get the focus and does some action but it doesn't dissapear (it should) and X is locked, even if the mouse moves.

This is not a realiable way to reproduce the problem, but most times I get it is like this. 

Debian unstable (server 1.4.1 and intel 2.2 driver). I would like to note that this problem didn't happen on server 1.4.

Sorry, but I haven't test the patch, this is a backtrace on my x64_64 laptop:
#0  0x000000000045a09b in ComputeFreezes () at ../../dix/events.c:1164
#1  0x00000000004551d1 in ProcUngrabKeyboard (client=0x8ccb40)
    at ../../dix/events.c:4296
#2  0x000000000044e3d2 in Dispatch () at ../../dix/dispatch.c:502
#3  0x0000000000436bcc in main (argc=8, argv=0x7fffe198e7d8,
    envp=<value optimized out>) at ../../dix/main.c:452

Thanks.

pushed to master as 50e80c39870adfdc84fdbc00dddf1362117ad443

In https://bugs.freedesktop.org/show_bug.cgi?id=13688#c8 (8th comment of bug 13688), discussing the patch in this bug’s comment 1, lonefox@welho.com writes:

> That patch fixes the IceWM crash... but replaces it with another bug. Now when
> I press backspace first time after using the dialog, the server quits without
> any error message, like if I had pressed control-alt-backspace instead.

I haven’t yet tried the current server again since commit 50e80c39870adfdc84fdbc00dddf1362117ad443 was pushed, but expect to do so Sunday.

I’ll follow up on whether I also see the undesired server-quit.

After having check that Debian unstable solves this (git20071212) I still have found some important issues detailed on https://bugs.freedesktop.org/show_bug.cgi?id=13937

(In reply to comment #5)
> After having check that Debian unstable solves this (git20071212) I still have
> found some important issues detailed on
> https://bugs.freedesktop.org/show_bug.cgi?id=13937


I'm pretty sure #13937 has a different cause. Marking this bug as fixed.

> I'm pretty sure #13937 has a different cause. Marking this bug as fixed.

I don't know. I have only changed 2 lines in 1.4.0.90

https://bugs.freedesktop.org/show_bug.cgi?id=13937#c1

So it's not complete solution. 
I have reopened this bug. If you want more information I can play with GDB/add some printfs if you tell me where. It's very annoying bug.

(In reply to comment #7)
> > I'm pretty sure #13937 has a different cause. Marking this bug as fixed.
> 
> I don't know. I have only changed 2 lines in 1.4.0.90
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=13937#c1
> 
> So it's not complete solution. 
> I have reopened this bug. If you want more information I can play with GDB/add
> some printfs if you tell me where. It's very annoying bug.

does the autorepeat/whatever work before the bug is triggered? 

Yes. autorepeat works until I press:
(few times, combination of)
Win+KeyPad_Plus - Amarok turn up volume
Win+KeyPad_Minus - Amarok turn up volume
Win+Shift+KeyPad_Minus - Amarok seek forward
Win+B - Amarok next track

Last two are a bit CPU time consuming. BTW I have Core 2 Duo.

After that X freeze (without patch) or (with patch):

1. autorepeat does not working (everywhere). xset r rate doesn't change it
2. alt+tab will not change window focus (however xev prints alt and tab keys)
3. amarok playlist (only it, amarok search bar - same window) behave like Shift was pressed (multiple continuous  selection instead of track selection)

I can't reproduce this bug. Can you provide more information about how exactly you reproduce the bug?

Also, I'm pretty sure you're triggering a new bug somewhere in the abyss of xkb.

I encountered the bug when using ratpoison, too. The proposed workaround was not in place, then. After searching through the commits between v1.4 and 1.4.0.90 I found that commit
83e76fb3f7a89a237893c2b7df450d4f90eab52d
introduced the bug. If I reinstate the ProcessKeyboardEvents pointer in the COND_WRAP* macros in xkbActions, the X server won't loop endlessly.

*** Bug 14449 has been marked as a duplicate of this bug. ***

If I'm not mistaken (which isn't all that unlikely, this stuff is complex), there is a problem with the workaround:
If the sequence is Freeze - UNWRAP - Thaw - COND_WRAP (if that's possible?), then after thawing we'll have dev->public.processInputProc == dev->public.realInputProc, so the assignment device->public.processInputProc = proc in COND_WRAP goes through, allowing EnqueueEvent to escape.  It's just not as bad since we haven't replaced realInputProc with EnqueueEvent.

If you're still having issues with the workaround in place, the patch attached to bug #14449 might be worth a try.  In basically tries to enforce the invariant (in case of Freezing/Thawing, there might be other users of the mechanism) that
processInputProc == (!frozen ? realInputProc : EnqueueEvent).

Simon, Pawel, Raoul:
is this still a problem? Tom's patch is already in master, does it fix this issue?

Hello:

Peter thanks for caring.

I'm still running Debian unstable, which means xserver 1.4.1 with some cherry picked commits. Still with that the problem is "solved". This means, server usable, key combinations works but there's still a minor issue in my case.

My laptop has a volume slider, the one that triggered the bug. Now it almost works but once I move slightly the slider, I get the volumeup/volumedown event autorepeated continuously as I would have been pressed it without release. This continues like this till I press another key.

I'm not sure if this problem is still related to this bug, if not I'd consider this fixed.

Regards,

(In reply to comment #15)
> My laptop has a volume slider, the one that triggered the bug. Now it almost
> works but once I move slightly the slider, I get the volumeup/volumedown event
> autorepeated continuously as I would have been pressed it without release. This
> continues like this till I press another key.

this sounds a lot like a driver/device issue. Can you check the actual output of the device with evtest. This way we can narrow down whether X is autorepeating something or the device/kernel just giving us continuous events.

Thanks for the hint. I didn't really know how to tackle this. I'm attaching the evtest output. Once running I first pressed a regular key to test and then I moved the slider a little. When I stopped moving the slider, X was still receiving volume events but not evtest. This looks significant.

Regards,

Created attachment 16147 [details]
evtest output for keyboard.

(In reply to comment #17)
> Thanks for the hint. I didn't really know how to tackle this. I'm attaching the
> evtest output. Once running I first pressed a regular key to test and then I
> moved the slider a little. When I stopped moving the slider, X was still
> receiving volume events but not evtest. This looks significant.
>

have a look at the last event. VolumeDown is pressed (value 1), but no release event is ever sent. This would cause xkb to autorepeat. Makes sense?
Can you try to trigger the bug again, looking for exactly this to happen?

Thanks for worrying.

Yes Peter, that's exactly what happens. I'm attaching a more comprehensive evtest output.

Regards,

Created attachment 16204 [details]
evtest output for keyboard.

On Sun, Apr 27, 2008 at 04:59:24AM -0700, bugzilla-daemon@freedesktop.org wrote:
> Thanks for worrying.
> 
> Yes Peter, that's exactly what happens. I'm attaching a more comprehensive
> evtest output.

Okay.  Could you please file a bug on the kernel, stating exactly what
happens, your exact hardware (cat /proc/bus/input/devices, dmesg, lsusb,
maybe even lshal), giving the evtest log, and describing the problem --
key down events need a faked key release?  It's the kernel's job to give
us sensible output: we can't tell the difference between a key that's
being held down and a key which doesn't generate release events.

*** Bug 15519 has been marked as a duplicate of this bug. ***

Peter: what patch are you talking about?
commit 37b1258f0a288a79ce6a3eef3559e17a67c4dd96
in the master branch fixes this issue for me

(In reply to comment #24)
> Peter: what patch are you talking about?
> commit 37b1258f0a288a79ce6a3eef3559e17a67c4dd96
> in the master branch fixes this issue for me

cool thx.

Just for correctness, I'm marking this bug as FIXED instead of NOTABUG. The originally reported bug was in fact fixed, the other issue reported by Raul is a separate bug (and not ours)

*** Bug 16424 has been marked as a duplicate of this bug. ***