| Summary: | Gdm and gnome-session crash after boot | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | hobel <ulrich.hobelmann> |
| Component: | RPM Packages | Assignee: | Damien Lallement <mageia> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | Normal | CC: | davidwhodgins, eeeemail, ennael1, lovaren, mageia, olav, tmb, wilcal.int |
| Version: | 4 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | 4alpha1 4alpha2 mga4 | ||
| Source RPM: | gnome-shell-3.9.90-1.mga4.src.rpm | CVE: | |
| Status comment: | |||
| Attachments: |
journal.txt from 4alpha2 live dvd
journal64.txt from successful boot of 4alpha2 livedvd 64 journal-livecd.txt different crash gdb.txt (gnome-shell) gdb.2964.txt (gnome-shell) gdb.2618.txt (gnome-settings-daemon) gdb.2969.txt (gnome-settings-daemon) |
||
|
Description
hobel
2013-09-01 12:27:52 CEST
Also affecting the 4 alpha2 pre-release live iso images. Messge in journal is ... gnome-session[2372]: Unrecoverable failure in required component gnome-shell.desktop No other log messages found. CC:
(none) =>
davidwhodgins, eeeemail, ennael1, tmb hobel, can you confirm this was under virtualbox? I just tested on real hardward, and it seems to only be happening in vb. CC:
(none) =>
mageia
Dave Hodgins
2013-09-01 22:35:54 CEST
Summary:
Gdm and gnome-session crash after boot =>
Gdm and gnome-session crash after boot in vb No, sorry, this is an actual installation on an Acer laptop with Intel graphics. I don't see the "Unrecoverable failure" you posted, but I get segfault messages in "dmesg" output. (or where can I see those journal messages?)
hobel
2013-09-02 06:24:00 CEST
Summary:
Gdm and gnome-session crash after boot in vb =>
Gdm and gnome-session crash after boot
claire robinson
2013-09-02 09:43:48 CEST
CC:
(none) =>
olav Created attachment 4304 [details]
journal.txt from 4alpha2 live dvd
Attaching journal.txt from 4alpha2 gnome livedvd 32
Clicking to log out when it fails attempts to restart gdm, which then fails again which can be seen in the journal.
claire robinson
2013-09-02 09:56:10 CEST
CC:
(none) =>
wilcal.int Created attachment 4305 [details]
journal64.txt from successful boot of 4alpha2 livedvd 64
Adding the journal from a successful boot of 4alpha2 livedvd 64bit in case it's useful for comparison.
Hmm, I've seen a few different problems around the same general theme recently. In VirtualBox there seems to be a BadValue X exception that kills gnome-shell and results in a blank screen instead of gdm login. You can see this being reported via the gdm user's journal (and in the main journal too) Claire's crash seems to be in libglib but we'd really need some kind of backtrace to work out the problem there. It's a little tricky to do that, but I think it would basically involve running gdb in "listen" mode waiting for gnome-shell to be run and then immediately attaching to it and allowing the crash to be caught and a backtrace made. Either that or somehow get it to dump it's core. Perhaps try replacing the /usr/bin/gnome-session binary a small script to run "ulimit -c unlimited" and then run the real binary with the --debug argument. I've not tested the ulimit thing but I do this trick to get it running in debug mode. If the ulimit works then you'll get a nice core that can be analysed. Hobel, to see journal messages just do "journalctl". To limit them to the current boot, "journalctl -b" Can you search and see if it's similar to Claire's output? Created attachment 4306 [details]
journal-livecd.txt different crash
Adding journal-livecd.txt from 4alpha2 gnome livecd
Similar symptom, crash on boot. It looks to be libgnome-desktop-3.so.7.0.0 this time.
Random thought... do these things use font-config? It was making firefox a bit crashy the other day, perhaps it's also making this stuff a bit crashy too? Latest font-config in cauldron seems better I think. Sorry that was gnome-settings crashing, above that there is also gnome-shell with libglib-2.0.so.0.3706.0 I've installed the livecd from the grub menu and confirmed the crash in an installed system. From tty2 I mv'd gnome-session to gnome-session-bin and created a script with #!/bin/bash ulimit -c unlimited gnome-session-bin exit Then rebooted. It created 4 large core files in /home/user/ which I've put into a folder called cores along with the journal.txt and compressed. https://dl.dropboxusercontent.com/u/4147101/mga4a2/cores.tar.xz Awesome thanks Claire, Unfortunately I don't have a 32-bit install available to analyse the cores... It seems the cores are from g-settings-daemon and g-shell (two each): core.2618: '/usr/libexec/gnome-settings-daemon' core.2811: '/usr/bin/gnome-shell' core.2964: '/usr/bin/gnome-shell' core.2969: '/usr/libexec/gnome-settings-daemon' Would you be able to do the following for me: gdb /usr/bin/gnome-shell core.2811 thread apply all bt full and the equiv for the other cores - passing the correct path and core name accordingly. Then attach the output (you can just do it in one big file if you like, but separate attachments is easier for comparing - if there are only two backtraces (i.e. the crash is the same for both gnome-shell cores and likewise for both g-s-d cores), then please just say that and only upload two in total :)) You may have to install some debuginfo packages for the bt to be really good, but even without symbols, our binaries might contain enough info to be useful anyway. Hopefully the crashes point to the same root cause :) Many thanks :) Created attachment 4307 [details]
gdb.txt (gnome-shell)
Just installed debuginfo-install gnome-shell-whatever.version.it.is.mga4.i586
gdb.txt attached, taken with 'set logging on' so it missed the first bit but has the full backtrace.
Created attachment 4308 [details]
gdb.2964.txt (gnome-shell)
Attaching the other gnome shell bt
Created attachment 4309 [details]
gdb.2618.txt (gnome-settings-daemon)
Created attachment 4310 [details]
gdb.2969.txt (gnome-settings-daemon)
And the two gnome-settings-daemon ones with it's debug info.
There are a bunch of other debug packages requested but I'm in a tty with no C&P.
Let me know asap please if you need any others as I need to install other isos there :)
claire robinson
2013-09-02 14:17:53 CEST
Attachment 4307 description:
gdb.txt =>
gdb.txt (gnome-shell) (In reply to claire robinson from comment #14) > Created attachment 4309 [details] > gdb.2618.txt (gnome-settings-daemon) So this one looks related to the XRandR extension support. There have been a few changes since the 3.9.90 release upstream related to this which may help although it's hard to say without trying. https://git.gnome.org/browse/gnome-desktop/log/ I've built a few packages here but I'm not sure it'll help. (In reply to claire robinson from comment #14) > Created attachment 4309 [details] > gdb.2618.txt (gnome-settings-daemon) OK, I think this is https://bugzilla.redhat.com/show_bug.cgi?id=1002055 and https://bugzilla.gnome.org/show_bug.cgi?id=707267 and fixed just a couple seconds ago by https://git.gnome.org/browse/mutter/commit/?id=46f4ea7 It explains why I don't get it on my x86_64 box but you do on your 32bit one. I think we'll need to rebuild a fair few gnome packages to resolve this (mutter certainly but then also gnome-desktop to use some of the mutter stuff and then everything that uses libgnome-desktop3_N because the N (libmajor) is bumped from 7 to 8. With the latest wave of packages, gdm starts up and logs into gnome-shell (which has a few weird graphics glitches now, but nothing dangerous :) ). Anyway, looks like this bug is fixed (on this system at least). Thanks for all the work you guys!! I'll definitely take some time now to acquaint myself with gdb and friends, so I can dig a bit deeper myself next time. gnome-shell 3.9.90-1.mga4 gdm "" mutter 3.9.90-5 gnome-desktop 2.32.1-4 glib2.0 2.37.7-1 Status:
NEW =>
RESOLVED Kudos to hobel :-)) I can reproduce this in a freshly installed Mageia 4 for x86_64 on my Toshiba Satellite L755-1DR laptop. I even tried rebuilding the src.rpm for gdm, but still the same result. Status:
RESOLVED =>
REOPENED Hi Kristoffer, I think it's best if you open a new bug and attach all relevant information (e.g. which hardware and what driver you are using, a backtrace of the crash etc) There are so many possible variations that can trigger this kind of problem that it doesn't seem correct to reopen an existing bug in this case. Status:
REOPENED =>
RESOLVED |