Bug 23048

Seems pretty clear to be a null pointer dereference:

 pEvdev = (EvdevPtr) 0x0

probably at this point:

    if (pEvdev->emulateMB.pending)

Dunno why pEvdev is 0x0 though.

Looks like it's the same as Fedora Bug 483297.
https://bugzilla.redhat.com/show_bug.cgi?id=483297

We haven't been able to identify the source of this bug and our attempts to reproduce it reliably were unsuccessful. We really need a reliable test case for this.

In 1 of the backtraces I have, it crashes from EvdevMBEmuTimer instead of EvdevMBEmuBlockHandler.

3: /usr/lib/xorg/modules/input//evdev_drv.so(EvdevMBEmuTimer+0x3f) [0xf00fcf]
4: /usr/lib/xorg/modules/input//evdev_drv.so(EvdevMBEmuWakeupHandler+0x59) [0xf010c9]

Just as the first poster in the Ubuntu bug, i have an
Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller
.  Similar to the Fedora bug, I have seen messages about a disabled USB port or hub.  I have experienced the bug in Debian as well.  I filed what is likely a duplicate bug report as FreeDesktop Bug 24170.

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

I've experienced this once.

I suppose a user work around should be possible to use the old mousedrv and keyboard driver instead of EvDev. I have not figured out how to do this.  Even if EvDev is not specified in xorg.conf and the other drivers are specified, the X server employs EvDev.

Two people say they got this crash using the following steps to produce the error:


A.  Just ran the following script to fix a stuttering mouse and got this crash.

#!/bin/sh
sudo btnx -k ; sudo modprobe -r usbhid ; sudo modprobe usbhid ; sudo btnx -b


B.  I was doing the following when this crash happened:

* I was running WinXP in Virtualbox with very heavy hard drive activity while on battery
* As I got the "Battery critically low" message, I plugged in AC, but apparently gpm did not recognize the plugging immediately
* So my laptop suspended (because I had configured that way) while running Virtualbox and heavy HDD (and possibly CPU) load
* After resume, I got thrown into VT1.
* I switched manually to VT7, and moments later a new X server started on VT8; after logging in, I got the apport crash handler.

My system is vulnerable to this bug, however
modprobe -r usbhid ; modprobe usbhid
does not reproduce it for me.

While we don't have a reproduction recipe for this bug yet, we do receive regular confirmation reports from Ubuntu users.  If it would be possible to add some instrumentation to the code to help track down the bug, we could ship such a patch in Ubuntu temporarily in order to harvest the logs when the bug turns up.

Does anyone want core dumps?

Created attachment 30107 [details] [review]
0001-Finalize-the-middle-button-emulation-when-a-read-err.patch

I think this should fix it. If I read the log right, the necessary steps to reproduce the bug are:

get a read error ENODEV on the device, hope that the reopen timer manages to find the device again if it comes back. Then really remove the device, possibly multiple times. Look out for a message like this in the log:

[32099.630886] (EE) HID 062a:0000: Read error: No such device
[32100.187449] (II) HID 062a:0000: Device reopened after 5 attempts.

If that message occurs, removing the device and re-adding should lead to a crash. The read error seems to be quite difficult to trigger, hence why I haven't been able to reproduce it myself. I would explain why removing the kernel module seems to work quite well.

Anyway, in the code, what happens is that in this case the reopen timer isn't removed. When the device is reopened, the timer is overwritten and the old one hangs around, eventually crashing the server.

Please test this patch and let me know if it works.

What version is your patch to?
It does not apply to the latest release.

(In reply to comment #12)
> What version is your patch to?
> It does not apply to the latest release.

Seems to apply fine on top of 2.2.99.2 and 2.2.5 here. Either way, it's just one line so if it doesn't apply locally you can just copy/paste the one line into the code manually.

I am testing the patch now. I had not known about the independant releases of modules.  4hours running and no crash yet.

Is there a way to disable middle button emulation altogether at the user level?
I know about
Option "Emulate3Buttons"
but I don't know how to apply it or whether it is possible because evdev scans for devices and creates InputDevices at runtime.

(In reply to comment #14)
> I am testing the patch now. I had not known about the independant releases of
> modules.  4hours running and no crash yet.

please try to reproduce the crash cases earlier, they all include some removal of the devices so if you can try to trigger it this way, please do so. normal usage of the desktop will almost certainly not trigger the bug unless you have busted hardware or you suspend/resume a lot.

> Is there a way to disable middle button emulation altogether at the user level?
> I know about
> Option "Emulate3Buttons"
> but I don't know how to apply it or whether it is possible because evdev scans
> for devices and creates InputDevices at runtime.

https://fedoraproject.org/wiki/Input_device_configuration
please don't hijack this bugreport for other issues though.

Perhaps due to my broken hardware, I must be a great candidate to test this bug.  I had crashes on average about every 3 to 4 hours on average. After a recent update of Xorg, the crashes diminished and GUI performance diminished.  Since applying the patch, I've had no crash.

>please don't hijack this bugreport for other issues though.

No need to worry that, in this case.  The disabling of middle button emulation would be a workaround for those afflicted by this issue.

Congratulations, it looks like you have found and fixed the bug!

Thanks for testing, pushed as f2dc0681febd297d95dae7c9e3ae19b771af8420. Will be in 2.3.0 shortly.