|Summary:||xserver-xorg-input-libinput crashes x server if bluetooth keyboard connected when screen is locked|
|Product:||Wayland||Reporter:||Joe Erickson <joe+freedesktop>|
|Component:||libinput||Assignee:||Peter Hutterer <peter.hutterer>|
|Status:||RESOLVED FIXED||QA Contact:|
|Priority:||medium||CC:||0.freedesktop, mgorse, peter.hutterer|
|i915 platform:||i915 features:|
Debug info gathered by reportbug
evemu-describe output for offending keyboard
Xorg crash log after patch
Description Joe Erickson 2016-07-28 17:52:49 UTC
Created attachment 125383 [details] Debug info gathered by reportbug From Debian Bug #832722 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832722 Package: xserver-xorg-input-libinput Version: 0.19.0-1 Severity: no * What led up to the situation? I can recreate this with the following steps: * Lock screen from inside window manager (Openbox) * Turn off bluetooth keyboard * Wait about 5 seconds * Turn on bluetooth keyboard * Wake system using bluetooth keyboard * LightDM comes up for login * Login using bluetooth keyboard * X crashes at some point and a new X session starts up as if it hadn't slept I did the sleep-wake cycle a couple of times without the bluetooth keyboard and couldn't get it to crash.
Comment 1 Peter Hutterer 2016-08-01 05:24:01 UTC
hmm, I wonder if the subdevice logic is broken here. Can you give me the evemu-describe output of this device (all of them if it has multiple event nodes)
Comment 2 Joe Erickson 2016-08-01 11:53:22 UTC
Created attachment 125462 [details] evemu-describe output for offending keyboard The evemu-describe output for the keyboard that is causing this issue. The keyboard is an Amazon Basics Bluetooth keyboard, Model #: KT-1081, ASIN: B005EOWBKE.
Comment 3 Peter Hutterer 2016-08-02 03:00:16 UTC
Can you reproduce it when the bt device is connected but you use a different keyboard to log in? Trying to figure out what exactly causes the issue here.
Comment 4 Joe Erickson 2016-08-02 19:57:05 UTC
I just had this happen, so here are the steps. I didn't touch the computer for about an hour, which means the BT keyboard would have went to sleep. I came back to the computer and hit the shift key on the BT keyboard a couple of times to wake the computer up. I remembered this issue and logged in with the keyboard on the laptop and, after logging in, had found that the X server had restarted. I also locked the screen and immediately logged in with the laptop keyboard while the BT keyboard is still connected and the X server did not restart. So just having the device connected doesn't seem to be the issue. The BT keyboard actually needs to be used while X is "sleeping" with the login screen for lightdm showing.
Comment 5 Peter Hutterer 2016-08-03 06:22:01 UTC
Created attachment 125499 [details] [review] 0001-Block-input-events-while-creating-the-virtual-subdev.patch Can you give this one a try please? the cause seems to be that the device sends events before the subdevice is fully initialized. I managed to reproduce this in gdb (mostly anyway) but I'm not sure I triggered the exact same race as you do.
Comment 6 Peter Hutterer 2016-08-08 23:45:09 UTC
Comment 7 Joe Erickson 2016-08-10 16:01:56 UTC
Created attachment 125673 [details] Xorg crash log after patch Finally got around to test this but it's still a problem. It seems like my bluetooth keyboard is now ignored before I can log into lightdm, but X still crashes if I press a key on it to wake it up.
Comment 8 Peter Hutterer 2016-08-11 08:37:01 UTC
any chance you can attach gdb to it (from another machine) and get more of a backtrace? otherwise, try addr2line to figure out which invocation of libinput_device_config_tap_get_finger_count we're crashing here.  I can't quite figure out where the race is, it could be during set up or during input event reading.  http://who-t.blogspot.com.au/2014/02/making-sense-of-backtraces-with.html
Comment 9 Peter Hutterer 2016-08-23 03:23:39 UTC
fwiw, I tested server 1.18.4 with xf86-input-libinput from git while running the libinput test suite. That one creates about 5000 devices in 5 minutes and triggers a lot of the race conditions we've seen during device startup (and highly likely yours is one of those). With 0168716fa I can finish the libinput test suite run without any crashes, suggesting that whatever you saw is probably fixed. If you can try xf86-input-libinput from git, that'd be great, thanks.
Comment 10 Peter Hutterer 2016-09-12 22:37:30 UTC
Comment 11 Mike Gorse 2016-09-20 21:07:15 UTC
Created attachment 126677 [details] Backtrace. I am seeing what I suspect is the same crash that Joe is seeing. For me, it shows up if I switch to a virtual console, then attach a USB keyboard. I am using libinput 1.5.0 and xf86-input-libinput from git (I first saw the crash on my main laptop, which has 0.19.0, so I tried updating after I found this bug, but it did not help.) Backtrace attached. Let me know if there is anything else you'd like me to provide.
Comment 12 Peter Hutterer 2016-09-21 07:26:45 UTC
you'll need to try libinput from git, I don't have a release for these fixes yet
Comment 13 Peter Hutterer 2016-09-21 07:27:03 UTC
xf86-input-libinput from git, sorry, libinput itself doesn't matter
Comment 14 Mike Gorse 2016-09-21 14:25:12 UTC
The trace that I attached was with xf86-input-libinput from git.
Comment 15 Peter Hutterer 2016-09-22 06:36:50 UTC
oh, whoops, sorry. I think I found the issue, not sure how quickly I'll get a patch out though. afaict the only way to reproduce this is when the parent device is disabled before the subdevice is added. not sure how exactly this is triggered though, but this seems like a design bug anyway.
Comment 16 Peter Hutterer 2016-10-19 04:28:57 UTC
(In reply to Mike Gorse from comment #11) > I am seeing what I suspect is the same crash that Joe is seeing. For me, it > shows up if I switch to a virtual console, then attach a USB keyboard. do you vt-switch back with that keyboard, or what triggers the crash? I'm trying to reproduce this here but no combination I tried so far triggered the crash.
Comment 17 Mike Gorse 2016-10-19 15:57:45 UTC
(In reply to Peter Hutterer from comment #16) > (In reply to Mike Gorse from comment #11) > > I am seeing what I suspect is the same crash that Joe is seeing. For me, it > > shows up if I switch to a virtual console, then attach a USB keyboard. > > do you vt-switch back with that keyboard, or what triggers the crash? I'm > trying to reproduce this here but no combination I tried so far triggered > the crash. If I switch to a virtual console, then attach a USB keyboard, then X crashes. I'm not at a point where I could switch back to my original X session with the keyboard attached, since X is already gone.
Comment 18 Peter Hutterer 2016-10-19 21:04:33 UTC
can I have the evemu-describe of your keyboard? I wonder if there's some property that matters.
Comment 19 Peter Hutterer 2016-11-14 20:45:45 UTC
Comment 20 Peter Hutterer 2016-11-15 00:49:48 UTC
Ok, I have a reproducer, it crashes with this backtrace when a mixed keyboard/mouse device is added (e.g. the Logitech K400) and this server flags are present: Section "ServerFlags" Option "AutoEnableDevices" "off" EndSection I doubt you have those locally, but somehow you trigger the same bug.
Comment 22 Peter Hutterer 2016-11-19 22:47:13 UTC
for the archives, the AED off simply serves to reproduce it with systemd-logind. I didn't originally reproduce it because of logind, the bug is reproducible without logind while VT-switched away (see the commit message too) commit 72bac84df9ce72f2baf730655ecc23f1692d1e64 Author: Peter Hutterer <email@example.com> Date: Tue Nov 15 11:23:08 2016 +1000 If the parent libinput_device is unavailable, create a new one