Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 106189
Summary: | GNOME Greeter crashes | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Adam H. Pendleton <fmonkey> | ||||
Component: | gdm | Assignee: | Havoc Pennington <hp> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike McLean <mikem> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | rawhide | CC: | alexl, braden, djh, edwardam, gczarcinski, jirka, jrb, kmaraas, kopa, krmaxwell, lrwclock, marc.deslauriers, mbarrientos, me, mhowell, mike, nphilipp, oliva, pmatilai, redhat-bugzilla, rpn, trondeg, twaugh, zach | ||||
Target Milestone: | --- | Keywords: | Triaged | ||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2003-11-12 13:36:11 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 100643 | ||||||
Attachments: |
|
Description
Adam H. Pendleton
2003-10-03 15:25:26 UTC
I see this same thing after updating to all packages in the update channel as of 11:00 CDT on 10/3/03 Same behavoir noted here after installation via the RHN beta channel, and a subsequent reboot of the machine. (14H06 - EST - Fri. 03 Oct. 2003). Additional NOTE: the programs in my Gnome Startup are still present, but do NOT start. (viz: tkseti, kmail, licq) ... also I am *now unable* to login to the KDE desktop "cannot find login script ... will attempt gnome login session", and I get logged into the gnome desktop! I find now that I cannot *print*, either! "Unable to open USB device "usb/dev/usb/lp0": No such device. I guess this is because I'm actually logged in to the desktop in "Failsafe mode"? Hmm, not good. Seems like there is some issue with the base session script (BaseXsession key in the config) From the looks of it it's not installed. AFAIK it should point to /etc/X11/xdm/Xsession , if it points somewhere else, that is why it's failing. GDM will get very confused if it can't find this script but will attempt some sort of a login (just directly execing gnome-session in failsafe mode) The "can't use USB" thing would almost on the face of it look like a different problem entierly. The greeter crashing seems also a different problem. It would be useful to get some output using the debug option (config file) and see the output generated in /var/log/messages My guess is that a whole bunch of files don't get installed right. Confirm additional comment #3. There is no way to get into KDE. Since today's updates included a new kernel, I tested with an older one, (2.4.22-1.2061.nptl) with the same results. Another thought is that it might be processor dependent. I have an Athlon XP, and I remember Elton Woo as having an Athlon of some kind. I have the same problem on my Pentium 4. ARe these lines from /var/log/messages of any interest? Oct 3 16:34:16 gstpc su(pam_unix)[4971]: session opened for user root by gerry(uid=500) Oct 3 16:34:21 gstpc gconfd (root-5024): starting (version 2.4.0), pid 5024 user 'root' Oct 3 16:34:21 gstpc gconfd (root-5024): Resolved address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only config source at position 0 Oct 3 16:34:21 gstpc gconfd (root-5024): Resolved address "xml:readwrite:/root/.gconf" to a writable config source at position 1 Oct 3 16:34:21 gstpc gconfd (root-5024): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only config source at position 2 Oct 3 16:35:14 gstpc ntpd[4629]: kernel time discipline status change 41 Oct 3 16:36:18 gstpc ntpd[4629]: kernel time discipline status change 1 Oct 3 16:36:21 gstpc gconfd (root-5024): GConf server is not in use, shutting down. Oct 3 16:36:21 gstpc gconfd (root-5024): Exiting I can confirm that changing the line "BaseXsession" in /etc/X11/gdm/gdm.conf (line 103) to BaseXsession=/etc/X11/xdm/Xsession fixes all messages except the greeter crashing. On a default installation the line reads BaseXsession=/etc/X11/gdm/Xsession after all updates from the RHN channel. I have the same problem. I have a PIII machine. After I updated my system today with rhn I got the same msgs. The log file for gdm /var/log/gdm/0.log doesn't show any error. The file /var/log/message says: Oct 3 22:02:10 130 gdmgreeter[3874]: No default session link found. Using Failsafe GNOME. I also recreated the user to see if any msg changed but there was no difference at all. I had this same problem, and I changed my greeter theme to something other than bluecurve. I believe that is what corrected this for me. Reference Additional Comment #14. Changing the theme and REBOOTING made the GDM login screen appear, but I still got the error messages and logged into a default Gnome session. From comment #14 I gather that the spec file fails to patch the gdm.conf file properly. The default gdm.conf file did change a little bit between version 2.4.4.0 and 2.4.4.3 so I suppose the patch didn't apply. Furthermore there needed to be some adjustments to the config for everything to play nice which I suppose got somehow lost. I haven't looked at the new package but it sure does look like this is the problem. I've got the same problem as of this morning with the rawhide updates. I have the same exact, duplicating issue with profound consternation. From kernel message: Oct 5 10:13:59 raxet gdm(pam_unix)[6595]: session opened for user maxer by (uid=0) Oct 5 10:14:00 raxet gdm[6606]: gdm_slave_session_start: Cannot find or run the base Xsession script, will try GNOME failsafe Oct 5 10:14:19 raxet gconfd (maxer-6616): starting (version 2.4.0), pid 6616 user 'maxer' Oct 5 10:14:20 raxet gconfd (maxer-6616): Resolved address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only config source at position 0 Oct 5 10:14:20 raxet gconfd (maxer-6616): Resolved address "xml:readwrite:/home/raxet/.gconf" to a writable config source at position 1 Oct 5 10:14:20 raxet gconfd (maxer-6616): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only config source at position 2 This happens to me also on my Dell XPS T550 desktop machine. This is not a processor dependant bug. I believe the same problem hangs my Sony Vaio PCG-F350 laptop during the boot process. This is an older, 364 MHz Pentium II machine. If I want to use the Vaio at all I need to boot into runlevel 3. I also believe this issue may be breaking Ximian Evolution, which has had constant problems ever since Fedora Core was first released. Evolution is actually more stable under the initial Severn 1 release. Yup, I'm seeing this (greeter crashing and falling back to Gnome failsafe session) too after the latest updates, gdm version 2.4.4.3-1 I just built libart_lgpl-2.3.16-1, when this reaches rawhide. It might fix the greeter crashing problem. This problem also occured on a Compaq Armada M700 Laptop following the update performed yesterday to include the kernel update. The problem still exists (comment #22) with the libart_lgpl-2.3.16-1 update installed. However, there were other updates including a kernel update that I'll install. Just for the record: the graphical greeter works for me when using the bijou gdm theme from http://art.gnome.org/themes/gdm_greeter/257.php The problem still exists, in exactly the same fashion as my original bug post, with the latest updates on the test2 RHN channel. Downgraded gdm to verison 2.4.4.0-2, per suggestion by Sjoerd Mullender, to correct the problem. There's no need to continue confirming this bug I'd say ;-) Please report any success with libart_lgpl-2.3.16-1 when that becomes available, otherwise a new gdm package should be along in a day or two. Downgrading certainly should work around the problem for now. twaugh said the libart upgrade didn't fix it. Oh well, I just know that there was some asserts in the old libart that triggered in greeter. This is something else then. I can confirm that the problems still exists with libart_lgpl-2.3.16-1 installed. *** Bug 106371 has been marked as a duplicate of this bug. *** *** Bug 106376 has been marked as a duplicate of this bug. *** *** Bug 106344 has been marked as a duplicate of this bug. *** The "greeter crash" is not really a "greeter crash" if I'd understand it correctly. There is a slight bug where a theme not found will be reported as a crash, this is fixed upstream in CVS (will make 2.4.4.4 at some point too). This should really have nothing to do with libart. not looking at the packages themselves I'd say it's most likely a screwup in the gdm spec file. Other packages which might be screwed up and cause such things are xinitrc and the artwork package (whatever the name might be in fedora). I'm kind of thinking however that it is strange that the graphical greeter didn't load the circles theme, perhaps 1) circles is screwed (it is not screwed upstream) or 2) the gdm package spec file removes the circles theme. The greeter will try to load a theme called "circles" as a backup. *** Bug 106436 has been marked as a duplicate of this bug. *** Someone mentioned that switching to something other than the Bluecurve them, got it working after one crash. Some of you might want to test that to see if that at least gets you a better working system. gdm-2.4.4.3-4 (building now) will have the BaseXSession fix, but it still has the greeter crash. I'll start looking into that now. Ok, i tracked down the Bluecurve crash. Basically the new greeter_canvas_item.c has some code to try to linewrap text that doesn't fit. It then takes a string like "Shut _down", expands it to "Shut <u>d</u>own", and then tries to shorten it to fit. Of course, it accidentally picks "Shut <u>" when trying different sizes, which spews this warning: GnomeCanvas-WARNING **: Failed to set cell text from markup due to error parsing markup: Error on line 1 char 25: Element 'markup' was closed, but the currently open element is 'u' Then later it crashes inside pango when setting some other markup with: CRITICAL **: file pango-attributes.c: line 773 (pango_attr_list_unref): assertion `list->ref_count > 0' failed ** Segmentation fault gdm-2.4.4.3-5 which is building at the moment has a patch that fixes this problem for me. Please test it out. I downloaded gdm-2.4.4.3-5, the greeter now works perfect but i still can't get gnome to work properly (not sure if it has to do with this bug but i think so cause it worked before i updated gdm...)! I get this everytime i start gnome: "There was an error starting the GNOME Settings Daemon. Some things, such as themes, sounds, or background settings may not work correctly. The Settings Daemon restarted too many times. The last error message was: Child process did not give an error message, unknown failure occurred GNOME will still try to restart the Settings Daemon next time you log in." Just rebooted my computer once more and everything works fine... Sorry! gdm-2.4.4.3-5 fixes this. gdm-2.4.4.3-5 from RHN up2dates works here as well now. When will this be in rawhide?? Are rawhide and rhn beta channels different?? This is what I am seeing: ftp.redhat.com:/pub/redhat/linux/rawhide/i386/RedHat/RPMS> ls -l gdm* -rw-r--r-- 1 ftp ftp 1921467 Oct 06 16:26 gdm-2.4.4.3-3.i386.rpm lftp ftp.redhat.com:/pub/redhat/linux/rawhide/i386/RedHat/RPMS> Rawhide doesn't get pushed automatically, you probably just have to wait a bit. Until then, you can work around the errors by changing these settings in /etc/X11/gdm/gdm.conf: BaseXsession=/etc/X11/xdm/Xsession DefaultSession=default.desktop GraphicalTheme=circles You can change GraphicalTheme to whatever themes you have installed ("ls /usr/share/gdm/themes"), apparently only the default theme make problems with the older gdm version. Ok, add another metoo to the list. It looks like you guys have squashed yet another bug. IOW WORKSFORME Thanks!! George didn't like that patch, alex. He sent another one to try out. I'll try building gdm with it later today. Created attachment 95083 [details]
different patch
Well, i didn't like the linebreaking code at all. :) george: A better way to do this would probably be to split up the markup into separate text and attribute-lists. Then you don't have to fuck around with semi-parsing the markup, all you have to to is keep track of where you insert/remove stuff from the string and correct the corresponding offsets in the attribute-list. For instance, I think both patches gets all confused by escaped characters like ">". My patch was just a minimal change to avoid crashing, not in any way the "right" solution. The really right solution involves using PangoLayout for line-breaking anyway, but i'm not sure the canvas currently lets you set max-width for the pangolayout. When i say "split up" i mean calling pango_parse_markup() of course. This should now be closed? It seems like the new patch is buggy. kmaras reported it turning "Shut _Down" to "Steng ne_<u>d</u>" in norwegian. Even worse. He claims it actually displays "Steng ne_<u>d</u></u>". I.e. there is no underlines. Might be because markup parse fails due to the two closing tags. Changing the english text from "Shut_down" to "Steng ne_d" is an easy way to reproduce this behaviour. Steng ne_dd works though, so this must be some sort of corner case. Different bug entierly actually and I just fixed it in HEAD on cvs. I will make a new upstream release tomorrow. A simple fix is to take greeter_item.c, find the place where 'underline--' and then there's a check like: if (underline == 0) g_string_append (str, "</u>"); change that to if (underline == 0) { g_string_append (str, "</u>"); underline = -1; } I fixed it in a more complicated way on HEAD, but the above should do. *** Bug 106860 has been marked as a duplicate of this bug. *** As far as I can see this bug is fixed. If anyone objects, one can always reopen the bug ;-). |