Steps to Reproduce: 0.Vanilla install, Czech language and keyboard 1.Insert your user name, press Caps Lock twice, press Enter 2.Insert the password, press Caps Lock twice 3.Boot into Failsafe session [not required, just for faster reproducing], press Enter to log in 4.In the terminal, enter setxkbmap -symbols 'czsk(us_cz_qwerty)' -compat group_led (This, except for s/symbols/layout/', is the setup I use in RHL 8.0 without these problems. -layout causes error messages in Phoebe) 5.Log out 6.Insert your user name, press Caps Lock twice, press Enter 7.Insert the password, press Caps Lock twice Actual results: Nothing unusual in 1., 2. and 6. After pressing Caps Lock for the second time in .7, X restarts. Expected results: Additional info:
I've experienced this bug too. I'll give my two cents to help isolate the conditions when it occurs. My system is a Toshiba Satellite 3000 laptop with the i686 kernel and the vesa driver under X driving the Nvidia Go chip. I doubt any of this matters though. To reproduce 1) My system boots into runlevel 5 2) For the username, type "a", then "A", then "a" using the CapsLock to change case. Notice the "You've got capslock on!" message being displayed. I'm not sure whether this step is strictly neccessary. 3) For the password, simply switch the CapsLock on then off. Notice that the "You've got capslock on!" message does not display. X/gdm-binary/gdmgreeter crashes as soon as CapsLock is switched off. I'm running the system with US English. I don't even need to logon with a valid username/password to trigger this bug. I tried debugging from the virtual console using strace and ltrace. Nothing crashes in such circumstances, but the "You've got capslock on!" message is not displayed, so I still know there is a bug. However, upon the killing of the ltrace or strace process monitoring the gdmgreeter process, a crash occurs when the user switches back to the X console (ie Alt-F7) without further keyboard input to gdm. My gut feeling is that it is gdmgreeter's fault.
You might check the gdm log files, and see if anything ended up in there.
From George: I'm wondering if this bug can be "fixed" by just setting: daemon/AlwaysRestartServer=true I'm starting to lean towards just making that the default since there just seem to be too many issues connected with just -HUP ing the X server. And perhaps remove the -HUPing code and always have the slave quit. I think I will do that right now in fact in CVS. It gives an ugly flicker since the X server will change vt to vt1 when it ends and then back to vt7, but oh well, who cares.
Altering the AlwaysRestartServer variable in /etc/X11/gdm/gdm.conf does not stop the bug from occuring. gdm/X/whatever still crashes. Furthermore, I've checked the /var/log/gdm/:0.log* files and there are no errors of any sort. Last line in these logfiles were: (==) Using config file: "/etc/X11/XF86Config" Incidentally, I've changed my greeter from the default "graphical" greeter to the "standard" greeter (which isn't the default, but still graphical) as seen in the program ``gdmsetup''. It doesn't crash anymore. The effect is that gdm-login is used rather than gdmgreeter. This points the bug squarely at gdmgreeter. Furthermore, using the "graphical" greeter, but with a different theme (either Circles or Happy GNOME) also seems to solve the problem -- odd. This indicates that either the theme (if it has code) has bugs in it or it is triggering bugs in gdmgreeter.
Taking gdm target/blockers.
I doubt this has/had anything to do with restarting the server or the Xkb configuration when logged in. Most likely it is/was some straightforward greeter crash. I can't reproduce it though.. Can you reproduce it with 2.4.1.0 from Rawhide?
Owen, if you're referring to me to install the package from Rawhide, you'd have to wait another few weeks. I've recently wiped phoebe and gone back to 8.0 for "Real Work". I might try the phoebe gdm on RH8.0 to see if I can reproduce the bug and the Rawhide gdm on RH8.0 to see if it can fix it. Might be a wait though.
Strange... Did another (fairly minimal) install, and it is now reproducible regardless of Xkb setting. Using the suggested package (although with --oldpackage, I didn't have gtk 2.2 final handy) causes the same. It is a crash in gdmgreeter, attaching traceback from the Phoebe 1 version. [Side note: Are/will the -debuginfo packages be available?]
Created attachment 89457 [details] Backtrace
Thanks for the backtrace -- apparently this is a libgnomecanvas bug, see: http://bugzilla.gnome.org/show_bug.cgi?id=102811 libgnomecanvas 2.2.0.1 is supposed to fix; so we need to upgrade that package.
libgnomecanvas 2.2.0.1 is in rawhide, so should be fixed now.
I indeed can't reproduce the crash with gdm-2.4.1.1-1 and libgnomecanvas- 2.2.0.1-1. BUT: 1) enter any username 2) start entering a password, press Caps Lock 3) enter a bad password Result: a "Password" field appears again, not "Username". Only way I know of to get back to the "username" prompt is Ctrl-Alt-Backspace.
I submitted that as bug 84626. Closing this one.