I've noticed strange behavior when using the vanilla evdev driver and shutting down X. If I move the mouse/press buttons while shutting down X it crashes with a back trace in either a motion event or button press event post function. I don't have a back trace handy at the moment but I do have a fix. It looks like EvdevProc is not shutting the driver down properly when X is shutdown. This is allowing events to be posted while the driver is in an inconsistent state at shutdown. Moving the DEVICE_CLOSE case in EvdevProc around as in the attached patch seems to fix this issue for me.
Created attachment 17985 [details] [review] Possible Fix
This should have been fixed by ac1db454497ff1839aa7f7ee0649ede112824ed9 in xserver. can you check this please?
(In reply to comment #2) > This should have been fixed by ac1db454497ff1839aa7f7ee0649ede112824ed9 in > xserver. can you check this please? > Nice, that appears to fix the issue.
Well, while the initial behavior I saw does appear to be resolved. It looks like there is a similar issue. From what I can tell, the *second* mouse connected to a system seems to be crashing during shutdown. (I'm using a laptop with built in touch pad which I don't normally use for anything, just happened to catch it during a shutdown ). I've tried several combinations and here's what I've seen: -> Logitech Marble Mouse on USB -> Alps Glidepoint internal -> Case 1, - Both devices present when X started - Motion on the Logitech during shutdown is fine, - Motion on the Alps causes X crash -> Case 2, - Logitech connected after X started - Motion on the Alps does not cause X crash - Motion on the Logitech causes X crash
Created attachment 18086 [details] Crash log This is for case 1 where both devices are connected at X start.
Created attachment 18087 [details] Crash log This is for case 2 where the track ball was not connected until after X started.
Comment on attachment 17985 [details] [review] Possible Fix Does not appear to fix the new behavior.
This appears in the current git version. It may be xserver rather than xf86-input-evdev. Not sure.
Interesting. I can the logs show that an event is being sent - most likely after the device has been shut down in some way. Shouldn't happen, since signals are blocked though. Can you attach gdb to it and give me the line + full backtrace where it fails? that might give some better hints for debugging.
Created attachment 18114 [details] Backtrace Ok, this should be a backtrace for the error. I had to rebuild to get debugging symbols. Since I'm using emerge/x11 overlay, rebuilding updated to the most recent git. My procedure for testing: -> start X by running gdb Xorg -> while moving the mouse, hit ctrl-alt-backspace (I'm not overly familiar with gdb so this might not be what you are looking for.)
> --- Comment #10 from Chris Salch <chrissalch@letu.edu> 2008-08-04 17:36:02 PST --- > Created an attachment (id=18114) > --> (http://bugs.freedesktop.org/attachment.cgi?id=18114) > Backtrace > > Ok, this should be a backtrace for the error. I had to rebuild to get > debugging symbols. Since I'm using emerge/x11 overlay, rebuilding updated to > the most recent git. > > My procedure for testing: > -> start X by running gdb Xorg > -> while moving the mouse, hit ctrl-alt-backspace > > (I'm not overly familiar with gdb so this might not be what you are looking > for.) looks like once the signal block terminates, the queued up signals cause the segfault. interesting, I've never seen this on my machine here, hence why I thought that the block/release signals patch fixed it.
Created attachment 18176 [details] Crash log
(In reply to comment #12) > Created an attachment (id=18176) [details] > Crash log > I have added my crash log too, I am also affected.
commit 465a9bb96e8a90e53e655b3245e22910201786d7 Author: Peter Hutterer <peter.hutterer@redhat.com> Date: Fri Aug 8 17:37:06 2008 +0930 dix: don't try to create events if we don't have a screen. #16898 A NULL screen may happen during server shutdown, when the output has been shut down but the devices still generate events. X.Org Bug 16898 <http://bugs.freedesktop.org/show_bug.cgi?id=16898>
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.