Comment 20 for bug 324368

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