Created attachment 24936 [details] system description This is the first time I've run Xorg under a debugger so I'm not sure what exactly I've debugged :-) In particular, I don't know how the SIGUSR1 signal was emitted. However, a crash looks always suspicious, and even under worst conditions Xorg should rather abort than crash IMHO. Attached is a file which shows my environment and all my used Xorg modules -- most notably, evdev is missing. I suppose this is the cause for the crash. Reading http://fedoraproject.org/wiki/Features/EvdevInputDriver I got the impression that it is sufficient to add Option "AutoAddDevices" "off" to revert to the old behaviour. Apparently, this doesn't work in my situation. I've started X as follows: XSERVER="/usr/local/x11/bin/Xorg" ARGS=":0 \ -nolisten tcp \ -verbose \ -config /etc/X11/xorg.conf.my" PID=$$ cat > /tmp/.dbgfile.$PID << HERE file $XSERVER set confirm off set args $ARGS handle SIGUSR1 nostop handle SIGUSR2 nostop handle SIGPIPE nostop run backtrace full quit HERE export LD_LIBRARY_PATH=/usr/local/x11/lib gdb --quiet \ --command=/tmp/.dbgfile.$PID &> /tmp/gdb_log.$PID chvt 1 rm -f /tmp/.dbgfile.$PID echo "Log written to: /tmp/gdb_log.$PID" After the crash I pressed the power-off button. I still have to experiment how to avoid this so that I get a visible prompt again... Below you can see the output of the gdb_log.$PID file not present in the attachment. ========================================================================== Program received signal SIGUSR1, User defined signal 1. Program received signal SIGSEGV, Segmentation fault. 0x080cc4fe in xf86ReleaseKeys (pDev=0x86b23a8) at xf86Events.c:408 408 for (i = keyc->xkbInfo->desc->min_key_code; #0 0x080cc4fe in xf86ReleaseKeys (pDev=0x86b23a8) at xf86Events.c:408 keyc = (KeyClassPtr) 0x86b2760 i = 140950752 j = 136790624 nevents = 136784112 sigstate = 136691416 #1 0x080cc6e3 in xf86VTSwitch () at xf86Events.c:469 i = 1 prevSIGIO = -1080327960 pInfo = (InputInfoPtr) 0x86b1f40 ih = (IHPtr) 0x0 #2 0x080cc313 in xf86Wakeup (blockData=0x0, err=-1, pReadmask=0x824eb20) at xf86Events.c:293 LastSelectMask = (fd_set *) 0x824eb20 devicesWithInput = {fds_bits = {134874126, 136726336, -1216004108, -1080327896, -1216136287, 136724680, 136780864, 10191160, 136724680, 136726336, -1208766476, -1080327832, -1208784729, 136790624, 2, 1, 136782376, 1, 136782360, 0, 136780864, 0, 0, 0, 136790624, 136780864, -1208766476, -1080327784, -1208785068, 0, 0, -1}} pInfo = (InputInfoPtr) 0x0 #3 0x08094c38 in WakeupHandler (result=-1, pReadmask=0x824eb20) at dixutils.c:418 i = 0 j = -1213520931 #4 0x080a9a88 in WaitForSomething (pClientsReady=0x866ff30) at WaitFor.c:231 i = -1 waittime = {tv_sec = 583, tv_usec = 320000} wt = (struct timeval *) 0xbf9b8408 timeout = 591168 clientsReadable = {fds_bits = {0 <repeats 32 times>}} clientsWritable = {fds_bits = {-1216004108, -1080327368, -1208393434, -1080327388, 7, 140962168, 1688, -1213901052, -1212935816, 1673, 82, 18, 2, 140962576, 4, 140964320, -1212935872, 2, 141240152, 7, 140964560, 24, 136780800, -1212935824, -1212935824, 140962568, 1647276915, 209, 140955832, 0, -1212940300, 0}} curclient = 134645920 selecterr = 4 nready = 0 devicesReadable = {fds_bits = {0 <repeats 32 times>}} now = 98790 someReady = 0 #5 0x080763cd in Dispatch () at dispatch.c:358 clientReady = (int *) 0x866ff30 result = 134903563 client = (ClientPtr) 0x6cc nready = -1 icheck = (HWEventQueuePtr *) 0x824e2f4 start_tick = 136791464 #6 0x08068eb0 in main (argc=7, argv=0xbf9b85b4, envp=0xbf9b85d4) at main.c:396 i = 1 alwaysCheckForInput = {0, 1}
please attach the matching log file too so we can check what driver is active, etc. Looks like you VT switched to trigger this bug - is this reproducible or was it a once-off?
The log file is in the attachment too. And yes, it is always reproducible.
In repository xserver: commit ac13145dbcb284293582435409d8a90f276785c5 Author: Peter Hutterer <peter.hutterer@who-t.net> AuthorDate: Mon May 11 15:45:46 2009 +1000 xkb: if kbd init failed, NULL out the pointers after freeing them (#21278) In repository xf86-input-keyboard: commit 29f075db9f86aa7e5e01688a5fd5e0081210e16b Author: Peter Hutterer <peter.hutterer@who-t.net> AuthorDate: Mon May 11 15:30:23 2009 +1000 Return BadValue if the server failed to init the keyboard. (#21278) You need both commits to avoid this bug. FWIW, this bug was triggered because your xkeyboard-config configuration is busted. So after applying the patches, the server won't crash but your keyboard won't work until you've re-installed xkeyboard-config in the right places.
??? What do you mean with `busted'? I've used the actual git version of xkeyboard-config.
from the Xorg.log (EE) XKB: Couldn't open rules file /usr/local/x11/share/X11/xkb/rules/xfree86 It looks like X is searching in a different path than xk-c is installed.
Interesting. Is it possible that this is a bug during a `make install'? Here's the list of files which get installed in .../X11/xkb/rules: base base.lst base.xml evdev evdev.lst evdev.xml README xfree98 xkb.dtd The necessary soft links are missing.
xfree86 was renamed to base a while ago, so I'm not sure what the status of the links is, Sergey (the xk-c maintainer) may know more. Either way, changing your config to use "base" instead should do the job.
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.