Bug 21278 - crash in xf86ReleaseKey if no evdev module is present
Summary: crash in xf86ReleaseKey if no evdev module is present
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/evdev (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Peter Hutterer
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-18 22:28 UTC by Werner Lemberg
Modified: 2009-05-11 00:07 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
system description (61.80 KB, text/plain)
2009-04-18 22:28 UTC, Werner Lemberg
no flags Details

Description Werner Lemberg 2009-04-18 22:28:45 UTC
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}
Comment 1 Peter Hutterer 2009-04-19 23:47:14 UTC
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?
Comment 2 Werner Lemberg 2009-04-20 00:24:50 UTC
The log file is in the attachment too.

And yes, it is always reproducible.
Comment 3 Peter Hutterer 2009-05-10 22:57:44 UTC
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.
Comment 4 Werner Lemberg 2009-05-10 23:02:00 UTC
???  What do you mean with `busted'?  I've used the actual git version
of xkeyboard-config.
Comment 5 Peter Hutterer 2009-05-10 23:07:31 UTC
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.
Comment 6 Werner Lemberg 2009-05-10 23:36:20 UTC
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.
Comment 7 Peter Hutterer 2009-05-11 00:07:17 UTC
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.