Ubuntu
xserver-xorg-input-evdev package

Xorg crashed with SIGSEGV in EvdevMBEmuBlockHandler()

Bug #343528 reported by Nawaf Alsallami
230
This bug affects 38 people
Affects Status Importance Assigned to Milestone
X.Org X server
Fix Released
Critical
xserver-xorg-input-evdev (Ubuntu)
Fix Released
High
Bryce Harrington

Bug Description

I wasn't doing anything new the time this program crashed. The screen went blank for a few seconds with some vertical colored strands crossing here and there Then, a command-line display came up with a few error messages. The system then went to the login window. From there everything worked fine. I have a feeling that this happened because I'm putting too much pressure on my machine. At the time I was having wuala, transmission, firefox, xchat working. And by the way, this is not the first time this crash happened but I didn't get the crash report in previous crashed because I've rebooted the system right after it happened.

$ lsb_release -rd
Description: Ubuntu jaunty (development branch)
Release: 9.04

ProblemType: Crash
Architecture: i386
DistroRelease: Ubuntu 9.04
ExecutablePath: /usr/bin/Xorg
Package: xserver-xorg-core 2:1.6.0-0ubuntu1
ProcAttrCurrent: unconfined
ProcCmdline: /usr/X11R6/bin/X :0 -br -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7
ProcEnviron:
 LANGUAGE=ar_SA:ar
 PATH=(custom, no user)
 LANG=ar_SA.UTF-8
ProcVersion: Linux version 2.6.28-9-generic (buildd@palmer) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu2) ) #31-Ubuntu SMP Wed Mar 11 15:43:58 UTC 2009
Signal: 11
SourcePackage: xorg-server
StacktraceTop:
 EvdevMBEmuBlockHandler ()
 BlockHandler ()
 WaitForSomething ()
 Dispatch ()
 main ()
Title: Xorg crashed with SIGSEGV in EvdevMBEmuBlockHandler()
Uname: Linux 2.6.28-9-generic i686
UserGroups:

[lspci]
00:00.0 Host bridge [0600]: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller [8086:2590] (rev 03)
     Subsystem: Toshiba America Info Systems Device [1179:ff31]
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2592] (rev 03)
     Subsystem: Toshiba America Info Systems Device [1179:ff31]

See original description
Revision history for this message
Nawaf Alsallami (nawaf) wrote :
Revision history for this message
Apport retracing service (apport) wrote : Symbolic stack trace

StacktraceTop:EvdevMBEmuBlockHandler (data=0x95474d0, waitTime=0xbff23c68,
BlockHandler (pTimeout=0xbff23c68, pReadmask=0x81f72e0)
WaitForSomething (pClientsReady=0x952d838)
Dispatch () at ../../dix/dispatch.c:367
main (argc=10, argv=0xbff23db4, envp=)

Revision history for this message
Apport retracing service (apport) wrote : Symbolic threaded stack trace
Changed in xorg-server:
importance: Undecided → Medium
Bryce Harrington (bryce)
tags: added: crash
Changed in xorg-server (Ubuntu):
status: New → Confirmed
Bryce Harrington (bryce)
visibility: private → public
Bryce Harrington (bryce)
description: updated
Revision history for this message
Matt Zimmerman (mdz) wrote :

I just saw this as well, on current Karmic. I was resuming from suspend, and saw the text console instead of my session, then a new X server was spawned. It left behind an apport crash report with a stack trace very similar to this one. I've never seen this crash before, and now it has 4 reports in Karmic, so I'm marking it as a regression.

Changed in xorg-server (Ubuntu):
status: Confirmed → Triaged
tags: added: regression-potential
Revision history for this message
Matt Zimmerman (mdz) wrote :

I found earlier reports from 9.04, so I guess it isn't a regression in Karmic, perhaps just rare.

It seems ready to be sent upstream.

tags: removed: regression-potential
Revision history for this message
Fabien Tassin (fta) wrote :

Just happened to me on karmic, a few minutes after a boot (no resume, real cold boot)

Revision history for this message
Colin Watson (cjwatson) wrote :

I just saw this too, while doing nothing very special, just editing a text file. I'm taking the liberty of reassigning this over to xserver-xorg-input-evdev, which seems to include the function that's crashing.

The text of the function is short enough to paste here:

void EvdevMBEmuBlockHandler(pointer data,
                            struct timeval **waitTime,
                            pointer LastSelectMask)
{
    InputInfoPtr pInfo = (InputInfoPtr) data;
    EvdevPtr pEvdev= (EvdevPtr) pInfo->private;
    int ms;

    if (pEvdev->emulateMB.pending)
    {
        ms = pEvdev->emulateMB.expires - GetTimeInMillis ();
        if (ms <= 0)
            ms = 0;
        AdjustWaitForDelay (waitTime, ms);
    }
}

affects: xorg-server (Ubuntu) → xserver-xorg-input-evdev (Ubuntu)
Revision history for this message
In , Bryce Harrington (bryce) wrote :

Created an attachment (id=28207)
ThreadStacktrace.txt

Forwarding this widely reported Ubuntu bug:
https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/343528

[Problem]
X crash in EvdevMBEmuBlockHandler() seen in Jaunty and Karmic (with -evdev 2.2.2). Occurs rarely, with no obvious/known steps to reproduce.

[Original Report]

I wasn't doing anything new the time this program crashed. The screen went blank for a few seconds with some vertical colored strands crossing here and there Then, a command-line display came up with a few error messages. The system then went to the login window. From there everything worked fine. I have a feeling that this happened because I'm putting too much pressure on my machine. At the time I was having wuala, transmission, firefox, xchat working. And by the way, this is not the first time this crash happened but I didn't get the crash report in previous crashed because I've rebooted the system right after it happened.

$ lsb_release -rd
Description: Ubuntu jaunty (development branch)
Release: 9.04

ProblemType: Crash
Architecture: i386
DistroRelease: Ubuntu 9.04
ExecutablePath: /usr/bin/Xorg
Package: xserver-xorg-core 2:1.6.0-0ubuntu1
ProcAttrCurrent: unconfined
ProcCmdline: /usr/X11R6/bin/X :0 -br -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7
ProcEnviron:
 LANGUAGE=ar_SA:ar
 PATH=(custom, no user)
 LANG=ar_SA.UTF-8
ProcVersion: Linux version 2.6.28-9-generic (buildd@palmer) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu2) ) #31-Ubuntu SMP Wed Mar 11 15:43:58 UTC 2009
Signal: 11
SourcePackage: xorg-server
StacktraceTop:
 EvdevMBEmuBlockHandler ()
 BlockHandler ()
 WaitForSomething ()
 Dispatch ()
 main ()
Title: Xorg crashed with SIGSEGV in EvdevMBEmuBlockHandler()
Uname: Linux 2.6.28-9-generic i686

Revision history for this message
In , Bryce Harrington (bryce) wrote :

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.

Revision history for this message
Bryce Harrington (bryce) wrote :

Seems pretty clear to be a null pointer dereference:

 pEvdev = (EvdevPtr) 0x0

probably at this point:

    if (pEvdev->emulateMB.pending)

The attached patch should paper over this particular crash.

Revision history for this message
Bryce Harrington (bryce) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xserver-xorg-input-evdev - 1:2.2.2-1ubuntu2

---------------
xserver-xorg-input-evdev (1:2.2.2-1ubuntu2) karmic; urgency=low

  * Add 100_mbemu_nullptr.patch: Null pointer checks for MBEmu*().
    (LP: #343528)

 -- Bryce Harrington <email address hidden> Thu, 30 Jul 2009 13:53:48 -0700

Changed in xserver-xorg-input-evdev (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Bryce Harrington (bryce) wrote :

I've also forwarded the issue upstream in case they want to look into it deeper - https://bugs.freedesktop.org/show_bug.cgi?id=23048 - if anyone would be willing to follow up with upstream on the issue please subscribe to this bug report.

Bug Watch Updater (bug-watch-updater)
Changed in xorg-server:
status: Unknown → Confirmed
Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

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.

Revision history for this message
Bryce Harrington (bryce) wrote :

Upstream says they can't reproduce the bug and so need to have a reproducible test case before they'll investigate. But it sounds also like fedora runs into the same problem, so I'm guessing it's an upstream bug they just haven't dug into far enough yet.

Anyway, hopefully the patch I posted solves the issue for folks in Ubuntu at least; if not and if you'd be willing to work with upstream, please see if you can boil it down to a reproducible test case (e.g. try doing some action you think may trigger it really heavily, perhaps looped in a script).

Revision history for this message
Matt Zimmerman (mdz) wrote :

I saw a crash with a very similar backtrace:

0: /usr/bin/X(xorg_backtrace+0x26) [0x4f0026]
1: /usr/bin/X(xf86SigHandler+0x41) [0x4850d1]
2: /lib/libc.so.6 [0x7fd13c232560]
3: /usr/lib/xorg/modules/input//evdev_drv.so(EvdevMBEmuBlockHandler+0x1a) [0x7fd139bf3c6a]
4: /usr/bin/X(BlockHandler+0x85) [0x452025]
5: /usr/bin/X(WaitForSomething+0x141) [0x4edb51]
6: /usr/bin/X(Dispatch+0x92) [0x44dd02]
7: /usr/bin/X(main+0x3b5) [0x433fa5]
8: /lib/libc.so.6(__libc_start_main+0xfd) [0x7fd13c21dacd]
9: /usr/bin/X [0x433429]
Saw signal 11. Server aborting.

but I was already running xserver-xorg-input-evdev 1:2.2.2-1ubuntu2 with the patch. Is there potentially another place in the same function where it could be crashing?

Revision history for this message
Matt Zimmerman (mdz) wrote :

This is definitely still happening in current Karmic. I just got it again. Reopening.

Backtrace:
0: /usr/bin/X(xorg_backtrace+0x26) [0x4efff6]
1: /usr/bin/X(xf86SigHandler+0x41) [0x4850a1]
2: /lib/libc.so.6 [0x7f6d98ef7560]
3: /usr/lib/xorg/modules/input//evdev_drv.so(EvdevMBEmuBlockHandler+0x1a) [0x7f6d968b7c6a]
4: /usr/bin/X(BlockHandler+0x85) [0x451ff5]
5: /usr/bin/X(WaitForSomething+0x141) [0x4edb21]
6: /usr/bin/X(Dispatch+0x92) [0x44dcd2]
7: /usr/bin/X(main+0x3b5) [0x433fa5]
8: /lib/libc.so.6(__libc_start_main+0xfd) [0x7f6d98ee2acd]
9: /usr/bin/X [0x433429]
Saw signal 11. Server aborting.

Changed in xserver-xorg-input-evdev (Ubuntu):
status: Fix Released → Triaged
importance: Medium → High
Revision history for this message
U. B. (uborstnik) wrote :

This crash happens about 10-20% times when resuming from a suspend.

Bryce Harrington (bryce)
tags: added: jaunty
Bryce Harrington (bryce)
tags: added: karmic
Revision history for this message
Jim Kirkpatrick (jim-kirkpatrick) wrote :

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

Revision history for this message
Janne Hyötylä (janne-hyotyla) wrote :

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.

Revision history for this message
In , Kiri (kiri) wrote :

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.

Revision history for this message
Kiri (kiri) wrote :

I also have an
Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller
does anyone without an Intel graphics controller experience this bug?

X crashed also in
3: /usr/lib/xorg/modules/input//evdev_drv.so(EvdevMBEmuTimer+0x3f) [0xf00fcf]
4: /usr/lib/xorg/modules/input//evdev_drv.so(EvdevMBEmuWakeupHandler+0x59) [0xf010c9]
instead of EvdevMBEmuBlockHandler.

The crash has happened when the machine was idle or mostly idle with no user activity as well as under load.

Revision history for this message
In , Gordon Jin (gordon-jin) wrote :

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

Revision history for this message
In , Shahar Or (mightyiam) wrote :

I've experienced this once.

Revision history for this message
In , Kiri (kiri) wrote :

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.

Revision history for this message
In , Bryce Harrington (bryce) wrote :

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.

Revision history for this message
In , Kiri (kiri) wrote :

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

Revision history for this message
In , Matt Zimmerman (mdz) wrote :

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.

Revision history for this message
Matt Zimmerman (mdz) wrote :

I just got this again on current Karmic:

Backtrace:
0: /usr/bin/X(xorg_backtrace+0x26) [0x4f0086]
1: /usr/bin/X(xf86SigHandler+0x41) [0x485091]
2: /lib/libc.so.6 [0x7f38341c8530]
3: /usr/lib/xorg/modules/input//evdev_drv.so(EvdevMBEmuBlockHandler+0x1a) [0x7f3831b78eca]
4: /usr/bin/X(BlockHandler+0x85) [0x451ff5]
5: /usr/bin/X(WaitForSomething+0x141) [0x4edbb1]
6: /usr/bin/X(Dispatch+0x92) [0x44dd02]
7: /usr/bin/X(main+0x3b5) [0x433fa5]
8: /lib/libc.so.6(__libc_start_main+0xfd) [0x7f38341b3abd]
9: /usr/bin/X [0x433429]
Saw signal 11. Server aborting.

Matt Zimmerman (mdz)
tags: added: regression-release
Revision history for this message
In , Njw (njw) wrote :

Does anyone want core dumps?

Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

Created an attachment (id=30107)
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.

Revision history for this message
Rob Frohne (frohro) wrote :

Hi,

I also have an Intel Mobile 915/GMS/910GML graphics controller. I am using wobbly windows, etc. and it occurs upon wakeup or suspend.

Hope this helps!

Rob

Revision history for this message
In , Kiri (kiri) wrote :

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

Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

(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.

Revision history for this message
In , Kiri (kiri) wrote :

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.

Bug Watch Updater (bug-watch-updater)
Changed in xorg-server:
status: Confirmed → In Progress
Revision history for this message
Matt Zimmerman (mdz) wrote :
Revision history for this message
Matt Zimmerman (mdz) wrote :

I've uploaded the above patch to my PPA: https://edge.launchpad.net/~mdz/+archive/ppa

Please test it, especially if you are able to reproduce this bug with some regularity.

Revision history for this message
Rick Spencer (rick-rickspencer3) wrote :

Bryce,

Could you please evaluate if Matt's patch is suitable for inclusion in Karmic?

Cheers, Rick

Changed in xserver-xorg-input-evdev (Ubuntu):
assignee: nobody → Bryce Harrington (bryceharrington)
Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

(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.

Revision history for this message
Zigue (techlabb) wrote :

This happened after resuming from a hibernate from me

Revision history for this message
Bryce Harrington (bryce) wrote :

Looks good

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xserver-xorg-input-evdev - 1:2.2.5-1ubuntu2

---------------
xserver-xorg-input-evdev (1:2.2.5-1ubuntu2) karmic; urgency=low

  * Apply upstream patch from fd.org bug 23048 (LP: #343528)
    Finalize the middle button emulation when a read error occurs (#23048)

    If a read error occurs, remove the block and wakeup handlers for middle
    mouse button emulation. Otherwise, they'll still be around after the device
    has been reopened and overwritten with the new ones created by EvdevOn.
    Once this happened, future removal of the device can lead to a server
    crash.

 -- Matt Zimmerman <email address hidden> Sun, 11 Oct 2009 09:47:44 +0100

Changed in xserver-xorg-input-evdev (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
In , Kiri (kiri) wrote :

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!

Revision history for this message
In , Peter Hutterer (peter-hutterer) wrote :

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

Bug Watch Updater (bug-watch-updater)
Changed in xorg-server:
status: In Progress → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in xorg-server:
importance: Unknown → Critical
Bug Watch Updater (bug-watch-updater)
Changed in xorg-server:
importance: Critical → Unknown
Bug Watch Updater (bug-watch-updater)
Changed in xorg-server:
importance: Unknown → Critical
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.