Hello, Xorg server crashed in mieqProcessDeviceEvent() in my armel environment. (xfree86 backend was used.) Callstack is like following: 0: gsignal+0x40(0x41dbc12c) [/lib/libc.so.6]+0x2c12c 1: abort+0x1b0(0x41dc19f8) [/lib/libc.so.6]+0x319f8 2: FatalError+0x68(0x6b20c) [/usr/bin/Xorg]+0x6320c 3: mieqProcessDeviceEvent+0x3c(0x62ed4) [/usr/bin/Xorg]+0x5aed4 4: mieqProcessInputEvents+0xa0(0x630c0) [/usr/bin/Xorg]+0x5b0c0 5: ProcessInputEvents+0x10(0x79090) [/usr/bin/Xorg]+0x71090 6: (0x400d9628) [/usr/lib/xorg/modules/input/evdev_drv.so]+0x3628 : EvdevDeleteSubDevice() 7: (0x400db404) [/usr/lib/xorg/modules/input/evdev_drv.so]+0x5404 : EvdevProc() 8: DisableDevice+0x128(0x39eac) [/usr/bin/Xorg]+0x31eac 9: RemoveDevice+0x200(0x3a214) [/usr/bin/Xorg]+0x32214 10: DeleteInputDeviceRequest+0x3c(0x74ac4) [/usr/bin/Xorg]+0x6cac4 11: (0x39934) [/usr/bin/Xorg]+0x31934 : CloseDownDevices() 12: (0x6acec) [/usr/bin/Xorg]+0x62cec : AbortServer() 13: FatalError+0x94(0x6b238) [/usr/bin/Xorg]+0x63238 14: __default_rt_sa_restorer_v2+0x0(0x41dbd4c0) [/lib/libc.so.6]+0x2d4c0 15: OsVendorFatalError+0x5c(0x7566c) [/usr/bin/Xorg]+0x6d66c 16: FatalError+0x7c(0x6b220) [/usr/bin/Xorg]+0x63220 17: mieqProcessDeviceEvent+0x3c(0x62ed4) [/usr/bin/Xorg]+0x5aed4 18: mieqProcessInputEvents+0xa0(0x630c0) [/usr/bin/Xorg]+0x5b0c0 19: ProcessInputEvents+0x10(0x79090) [/usr/bin/Xorg]+0x71090 20: (0x33c08) [/usr/bin/Xorg]+0x2bc08 : Dispatch 21: (0x26cc0) [/usr/bin/Xorg]+0x1ecc0 : main() 22: __libc_start_main+0x118(0x41da5364) [/lib/libc.so.6]+0x15364 In 16th frame FatalError() was called in CHECKEEVENT(ev) in mieqProcessDeviceEvent(). #define CHECKEVENT(ev) if (ev && ((InternalEvent*)(ev))->any.header != 0xFF) \ FatalError("Wrong event type %d.\n", \ ((InternalEvent*)(ev))->any.header); If the header of an event was wrong, FatalError() will be called. But the event was picked from the miEventQueue and every event was also checked by CHECKEVENT macro when queueing @miEventQueue. Is there any guys who can explain about this problem ?
*** Bug 28496 has been marked as a duplicate of this bug. ***
On Thu, Jun 10, 2010 at 19:59:39 -0700, bugzilla-daemon@freedesktop.org wrote: > 6: (0x400d9628) [/usr/lib/xorg/modules/input/evdev_drv.so]+0x3628 : > EvdevDeleteSubDevice() the evdev driver has no such function. what software are you running?
(In reply to comment #2) > On Thu, Jun 10, 2010 at 19:59:39 -0700, bugzilla-daemon@freedesktop.org wrote: > > > 6: (0x400d9628) [/usr/lib/xorg/modules/input/evdev_drv.so]+0x3628 : > > EvdevDeleteSubDevice() > > the evdev driver has no such function. what software are you running? Isn't that from the French multitouch stuff?
Yes, I'm using evdev-multitouch driver derived from the following url and it's working properly/ ==> http://cgit.freedesktop.org/~tissoire/xf86-input-evdev/log/?h=multitouch-unstable In my opinion, the main cause of this problem is between frame 16 and 17. An invalid event whose header is not equal to 0xFF (=ET_Internal) was in miEventQueue and it may cause FatalError() in frame 16. The reason FatalError() was called again in frame 13 is OccurSegFault() was called in OsVendorFatalError(). OccurSegFault() was added for causing SIGSEGV at FatalError(). ========================================================================== static void OccurSegFault(void) { *(char *) 0 = 0; } void OsVendorFatalError(void) { #ifdef VENDORSUPPORT ErrorF("\nPlease refer to your Operating System Vendor support pages\n" "at %s for support on this crash.\n",VENDORSUPPORT); #else ErrorF("\nPlease consult the "XVENDORNAME" support \n" "\t at "__VENDORDWEBSUPPORT__"\n for help. \n"); #endif if (xf86LogFile && xf86LogFileWasOpened) ErrorF("Please also check the log file at \"%s\" for additional " "information.\n", xf86LogFile); ErrorF("\n"); if (!xf86Info.caughtSignal) OccurSegFault(); } ==========================================================================
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.
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.