Bug 435104

Created attachment 296055 [details]
screenshot of the data

Still the same with the latest updates from koji:

libxkbfile-1.0.4-5.fc9.x86_64
xorg-x11-drv-keyboard-1.2.2-4.fc9.x86_64
xorg-x11-server-common-1.4.99.1-0.23.20080222.fc9.x86_64
xorg-x11-server-Xorg-1.4.99.1-0.23.20080222.fc9.x86_64
xorg-x11-server-utils-7.3-3.fc9.x86_64

Created attachment 296068 [details]
/var/log/Xorg.0.log

Created attachment 296069 [details]
/etc/X11/xorg.conf

Created attachment 296075 [details]
/var/log/messages

*** Bug 435183 has been marked as a duplicate of this bug. ***

I see a similar thing with one system, but another is not doing this.  However mine does not reset Xorg 
when I type a key it only resets when I try to login, then gdm restarts and the process repeats (type name, 
type password, Xorg restart, gdm restart).  It does not appear to be even trying to get into gnome yet at 
the point it fails and restarts gdm (nothing relevant in .xsession-errors).

I have problem with rhgb. At rhgb I press "space" then rhgb crashes. When it
comes to gdm, I can login without problem. This is several days ago, now I use
startx and disabled rhgb to boot faster (since it has some chance of freeze when
gnome starts I may have to reboot. BTW, if nautilus and gnome-panel crash, and
"alt" key lost response, what can I do to reboot safely?)

As of today I'm no longer getting gdm allowing me to type in username/pw, but I don't think my gdm 
version changed so something else must have.  It is not respawning immediately as soon as it displays the 
userlist window (I see 'Other' then it restarts gdm).

Yuan, if you have another machine you can login and restart via ssh.  If you don't have another machine, 
then put a terminal launcher on your desktop so you can try using that to open a terminal and reboot from 
there (assuming nautilus is showing your desktop but panel is crashed).  You could also configure a key in 
gnome to shutdown or logoff (then you'd just need to hit enter to exit).

That should have been 'it is now respawning immediately as soon as it displays the userlist'

Now everything crashes X session.  I type startx from level 3 and it goes 
down.  Is there something that we can do to make it work again.

Now everything crashes X session.  I type startx from level 3 and it goes 
down.  Is there something that we can do to make it work again.

In my case I tracked it down to a segfault in the X server code.  Reading the 
code, I don't see how that failure could be happening, which makes me think 
either the SIGALRM that comes in immediately ahead of the failure stomps on the 
stack somehow.

http://domsch.com/linux/fedora/xorg-segv-ltrace.txt shows the failure.  Look 
for SEGV and then back up a few lines.

Could all of you please, attach your /var/log/Xorg.0.log from the attempt to run
Xorg as a separate uncompressed attachment to this bug, please?

Created attachment 296293 [details]
Xorg.0.log

Created attachment 296359 [details]
recorded the session

Created attachment 296360 [details]
recorded the session

I think there are several different crashes going on here.

If I remove /etc/X11/xorg.conf such that X uses its effective built-in defaults,
I get it to crash on keypress in dix/getevents.c: GetKeyboardValuatorEvents():

    KeySym *map = pDev->key->curKeySyms.map;
    KeySym sym = map[key_code * pDev->key->curKeySyms.mapWidth];

However, curKeySyms.map is a NULL pointer, so boom.

Backtrace:

0: /usr/bin/X(xf86SigHandler+0x65) [0x47a705] (this is the SEGV handler)
1: /lib64/libc.so.6 [0x3293832ef0]

2: /usr/bin/X(GetKeyboardValuatorEvents+0x4a) [0x45680a]  (this is the real crash)
3: /usr/bin/X(GetKeyboardEvents+0x17) [0x456b77]
4: /usr/bin/X(xf86PostKeyboardEvent+0x7d) [0x4924ad]
5: /usr/lib64/xorg/modules/input//evdev_drv.so [0x1ae9b9b]
6: /usr/bin/X [0x47a855]
7: /usr/bin/X [0x46a4c7]
8: /lib64/libc.so.6 [0x3293832ef0]
9: /lib64/libc.so.6(__select+0x13) [0x32938de473]
10: /usr/bin/X(WaitForSomething+0x1db) [0x4e807b]
11: /usr/bin/X(Dispatch+0xa7) [0x445d47]
12: /usr/bin/X(main+0x45d) [0x42c6dd]
13: /lib64/libc.so.6(__libc_start_main+0xfa) [0x329381e36a]
14: /usr/bin/X(FontFileCompleteXLFD+0x281) [0x42bab9]


If I use an xorg.conf file that has Input sections for the mouse and keyboard,
it also crashes this way.

If I remove the InputDevice sections from my xorg.conf and use this ServerFlags
section instead, it fails the same way:
Section "ServerFlags"
        Option      "AllowEmptyInput" "True"
        Option      "AutoAddDevices" "True"
        Option      "AutoEnableDevices" "True"
EndSection

So, why is map NULL?

Created attachment 296370 [details]
xorg.conf

Potential solution for me.

First, read this:
https://www.redhat.com/archives/fedora-devel-list/2008-February/msg02131.html

Second, *don't* follow this for step 2 or later!  You *do* want this section in
your xorg.conf file:

Section "ServerFlags"
	Option	    "AllowEmptyInput" "True"
	Option	    "AutoAddDevices" "True"
	Option	    "AutoEnableDevices" "True"
EndSection

In my case, I also need to have a section for the Synaptics touchpad.  See my
attached xorg.conf.
 
Adding in the suggested file /etc/hal/fdi/policy/10-x11-keyboard-layout.fdi
turns out to be what broke hal, which is what caused the keyboard map to be
null.  So don't do this.  Here's what I get from hal now:

$ lshal | grep xkb
  input.xkb.layout = 'us'  (string)
  input.xkb.model = 'evdev'  (string)
  input.xkb.rules = 'base'  (string)
  input.xkb.variant = ''  (string)


And this works for me.

X really should complain loudly if it can't set up the key map, not just wait
for it to crash on keypress.

Should be working in 1.4.99.900-0.27.20080303.

I seem to be hitting this bug with
xorg-x11-server-Xorg-1.4.99.901-1.20080307.fc9.x86_64

$ cat /etc/X11/xorg.conf | grep Xkb
        Option          "XkbModel"              "pc105"
        Option          "XkbLayout"             "us,il"
        Option          "XkbOptions"    "grp:alt_shift_toggle,grp_led:scroll"
$ xinit
(type "exit" in X console)
....
Backtrace:
0: X(xf86SigHandler+0x65) [0x479d35]
1: /lib64/libc.so.6 [0x3089833000]
2: X(GetKeyboardValuatorEvents+0x3c) [0x45672c]
3: X(GetKeyboardEvents+0x17) [0x456aa7]
4: X(xf86PostKeyboardEvent+0x7d) [0x491add]
5: /usr/lib64/xorg/modules/input//evdev_drv.so [0x7326ab2]
6: X [0x479e85]
7: X [0x46a4f7]
8: /lib64/libc.so.6 [0x3089833000]
9: /lib64/libc.so.6(sigprocmask+0x10) [0x3089833230]
10: X(xf86UnblockSIGIO+0x2d) [0x469f4d]
11: /usr/lib64/xorg/modules//libint10.so(finish_int+0xb) [0x457d62b]
12: /usr/lib64/xorg/modules//libvbe.so(VBESetVBEMode+0xa0) [0x1bc4c30]
13: /usr/lib64/xorg/modules/drivers//vesa_drv.so [0x41afc0b]
14: /usr/lib64/xorg/modules/drivers//vesa_drv.so [0x41b165a]
15: X [0x501ebb]
16: X [0x522cf4]
17: X(main+0x4d4) [0x42c834]
18: /lib64/libc.so.6(__libc_start_main+0xfa) [0x308981e47a]
19: X(FontFileCompleteXLFD+0x279) [0x42bb99]

I managed to reproduce this crash twice.

- Gilboa

Could anybody reproduce this bug with the current updates of Rawhide (Beta and
post-Beta)? I certainly cannot and I think this bug should be CLOSED.

I was able to for a while, but after setting up X to use evdev for the 
keyboard properly, it went away.  After X changed again to not use evdev, the 
problem re-appeared.  I then removed X using evdev parts of the config, and 
it's working again.  Oh the joys of running rawhide. :-)

Note I don't think the actual bug is fixed, I think it just gets masked when 
you have a proper keyboard config (for whatever definition of "proper" X 
expects today.)

Fresh 9-B installation + updates seems to work just fine.
Thanks!

- Gilboa

(In reply to comment #25)
> Note I don't think the actual bug is fixed, I think it just gets masked when 
> you have a proper keyboard config (for whatever definition of "proper" X 
> expects today.)

Yes, but I think it should be masked for everybody -- after many bugs like this,
evdev was ripped from all default configuration and unless you want
intentionally inflict pain on yourself and install it manually it shouldn't
happen anymore in F9 (not until it is thoroughly debugged).

Closing as RAWHIDE.