Xorg crashed with SIGSEGV in XisbRead()

This happened during, or immediately after, a resume from RAM. I've suspended and resumed many other times without incident, so this may not be reproducible.

ProblemType: Crash
Architecture: amd64
DistroRelease: Ubuntu 9.04
ExecutablePath: /usr/bin/Xorg
Package: xserver-xorg-core 2:1.5.99.902-0ubuntu1
ProcAttrCurrent: unconfined
ProcCmdline: /usr/X11R6/bin/X :0 -br -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7
ProcEnviron:
 LC_COLLATE=C
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/zsh
ProcVersion: Linux version 2.6.28-6-generic (buildd@crested) (gcc version 4.3.3 (Ubuntu 4.3.3-3ubuntu1) ) #17-Ubuntu SMP Fri Jan 30 15:35:08 UTC 2009

Signal: 11
SourcePackage: xorg-server
StacktraceTop:
 XisbRead ()
 ?? ()
 ?? ()
 xf86Wakeup ()
 WakeupHandler ()
Title: Xorg crashed with SIGSEGV in XisbRead()
Uname: Linux 2.6.28-6-generic x86_64
UserGroups:

StacktraceTop:?? ()
?? ()
xf86Wakeup (blockData=<value optimized out>,
WakeupHandler (result=1, pReadmask=0x7ddf20)
WaitForSomething (pClientsReady=0x23dfaf0)

Catches the null pointer at least, though I'm not sure why synaptics would be passing a null in here.

Hi matt, I've forwarded this issue upstream to https://bugs.freedesktop.org/show_bug.cgi?id=19918 - please subscribe to that bug in case upstream has further questions or wishes you to test something. Thanks ahead of time.

Bryce

Kees just experienced the same crash during a resume, so this is no longer an isolated incident.

Patching for the null ptr seems to be an insufficient fix. But for a better fix upstream needs a reproducible test case.

Kees or Matt, either of you have steps for reproducing this crash? If it was a one-time only thing, it could be hard to find a fix.

Erf, ignore that debdiff. Trying to do too many things simultaneously.

On Tue, Feb 10, 2009 at 05:51:59PM -0000, Bryce Harrington wrote:
> Patching for the null ptr seems to be an insufficient fix. But for a
> better fix upstream needs a reproducible test case.
>
> Kees or Matt, either of you have steps for reproducing this crash? If
> it was a one-time only thing, it could be hard to find a fix.

Kees and I both experienced it independently, so it wasn't a one-time thing.
There is surely a bug here. Have you considered possible cases where the
null pointer could be passed in via the synaptics driver?

--
 - mdz

> Kees and I both experienced it independently, so it wasn't a one-time thing.
> There is surely a bug here.

Right, pretty clearly from the backtrace something did go wrong. It is exceptionally weird that this happened for both you and kees at roughly the same time, yet I gather that neither of you have seen it since then, and it appears few others have seen it (neither google nor launchpad turn up other bugs with 'XisbRead' crashes). It makes me think there is something very specific that is done to produce this bug, that both of you did. Kees mentioned he'd been plugging/unplugging from projectors, which seems unlikely to cause a crash in the mouse code, but stranger things have been known to happen.

> Have you considered possible cases where the null pointer could be passed in via the synaptics driver?

Yes, unfortunately the backtrace did not include symbols for the synaptics routines, so it's a bit of detective work to guess at the codepath, but XisbRead() only gets called a few places and it always passes the same parameter - a comm buffer. There's a few places where this is set to NULL, once at the beginning of driver initialization, and again in the code to turn the driver on and off. However, there are errors/warnings that would normally get printed in those conditions, which aren't appearing in your log. Very strange.

I wonder if perhaps there is a race condition where the suspend/resume occurred while the driver was in the middle of either the init, or in the middle of turning the device on/off. Some of the other warnings in the log indicate it was having trouble opening the device and retrying after a delay; maybe suspending while it was in the middle of a delay revealed the problem. I wish we had kees' Xorg.0.log for comparison.

I'm tentatively going to drop the priority on this to Medium for now since while it's a bad issue, it seems to occur quite infrequently. Although if we see more reports of this problem I'll bump it back up to High.

On Tue, Feb 17, 2009 at 09:26:33PM -0000, Bryce Harrington wrote:
> I wish we had kees' Xorg.0.log for comparison.

This is one of the down-sides of the dup-detector, as it encourages people
to not file a bug when one already exists for a given crash. I think it'd
be better for it to finish filing the bug, but the dup it (to gain the
backtraces and logs).

On Tue, Feb 17, 2009 at 09:50:15PM -0000, Kees Cook wrote:
> On Tue, Feb 17, 2009 at 09:26:33PM -0000, Bryce Harrington wrote:
> > I wish we had kees' Xorg.0.log for comparison.
>
> This is one of the down-sides of the dup-detector, as it encourages people
> to not file a bug when one already exists for a given crash. I think it'd
> be better for it to finish filing the bug, but the dup it (to gain the
> backtraces and logs).

In this case, of course, you decided not to file the bug when I said that I
had already done so. :-)

The dupe detector does work as you describe. It sounds like maybe you're
referring to bugpatterns, which are generally only used to suppress invalid
reports or to block bugs which are getting reported too frequently.

--
 - mdz

Both this and bug 328035 are crashes within xf86Wakeup on the same hardware. The backtraces and symptoms are different, but it's entirely possible they share a similar root cause.

I've patched in some extra debug messages to xf86Wakeup, which might give some additional clues (it spews quite a bit to the log though). I stuck the package on my ppa:

  https://edge.launchpad.net/~bryceharrington/+archive/ppa

For reference, here's my log when running with this patched Xserver. The log grows at a pretty quick clip, so I wouldn't recommend running this version except when trying to deliberately reproduce the behavior.

Upstream seems to be waiting for better steps to reproduce. But I'm assuming kees and mdz are not seeing the crash again due to their silence.

I've left my nullptr check patch aside up 'til now in the hope that further crashes would turn up so we could pinpoint the steps to reproduce. However, I feel it makes little sense to release Ubuntu without the check since we already know it can crash here even if infrequently. We can disable the patch during karmic development if we want to explore it further.

This bug was fixed in the package xorg-server - 2:1.6.0-0ubuntu3

---------------
xorg-server (2:1.6.0-0ubuntu3) jaunty; urgency=low

  * Add 165_man_xorg_conf_no_device_ident.patch:
    - Device identifier no longer necessary in Screen section of
      xorg.conf. Update man page accordingly.
      (LP: #261577)
  * Add 166_nullptr_xinerama_keyrepeat.patch:
    - Avoids null pointer dereference when holding down keys on
      non-primary screen when using TwinView / Xinerama on -nvidia.
      (LP: #324465)
  * Add 167_nullptr_xisbread.patch:
    - Avoids null pointer dereference in XisbRead to prevent a (difficult
      to reproduce) crash during or after a resume from RAM.
      (LP: #324368)

 -- Bryce Harrington <email address hidden> Thu, 19 Mar 2009 00:17:40 -0700