Bug 11124

Summary: Gdm and gnome-session crash after boot
Product: Mageia Reporter: hobel <ulrich.hobelmann>
Component: RPM PackagesAssignee: 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
Description of problem:
I installed the M4 alpha 1 i586 Gnome live CD, ran all updates, rebooted.

"Oh no! Something has gone wrong." is displayed, instead of gdm.

I also tried booting into runlevel 3 and running startx and gnome-session, but I get the same error.

dmesg mentions a segfault in libgnome-desktop (from gnome-settings) and in libglib (from gnome-shell).

Version-Release number of selected component (if applicable):
Since I'm not sure, which package(s) cause the problems: up-to-date M4 alpha 1 install with updates as of now.

How reproducible:
Boot the system.


Reproducible: 

Steps to Reproduce:
Comment 1 Dave Hodgins 2013-09-01 19:08:24 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
Assignee: bugsquad => mageia
Source RPM: (none) => gnome-shell-3.9.90-1.mga4.src.rpm

Comment 2 Dave Hodgins 2013-09-01 22:12:57 CEST
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

Comment 3 hobel 2013-09-02 06:23:42 CEST
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
Whiteboard: (none) => 4alpha1 4alpha2

Comment 4 claire robinson 2013-09-02 09:46:01 CEST
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

Comment 5 claire robinson 2013-09-02 10:42:17 CEST
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.
Comment 6 Colin Guthrie 2013-09-02 10:46:57 CEST
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?
Comment 7 claire robinson 2013-09-02 11:52:25 CEST
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.
Comment 8 Colin Guthrie 2013-09-02 12:02:25 CEST
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.
Comment 9 claire robinson 2013-09-02 12:04:31 CEST
Sorry that was gnome-settings crashing, above that there is also gnome-shell with libglib-2.0.so.0.3706.0
Comment 10 claire robinson 2013-09-02 13:11:44 CEST
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
Comment 11 Colin Guthrie 2013-09-02 13:39:02 CEST
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 :)
Comment 12 claire robinson 2013-09-02 13:56:36 CEST
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.
Comment 13 claire robinson 2013-09-02 14:07:05 CEST
Created attachment 4308 [details]
gdb.2964.txt (gnome-shell)

Attaching the other gnome shell bt
Comment 14 claire robinson 2013-09-02 14:07:56 CEST
Created attachment 4309 [details]
gdb.2618.txt (gnome-settings-daemon)
Comment 15 claire robinson 2013-09-02 14:11:01 CEST
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)

Comment 16 Colin Guthrie 2013-09-02 15:47:09 CEST
(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.
Comment 17 Colin Guthrie 2013-09-02 15:49:54 CEST
(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.
Comment 18 hobel 2013-09-02 21:19:46 CEST
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
Resolution: (none) => FIXED

Comment 19 William Kenney 2013-09-02 22:41:38 CEST
Kudos to hobel  :-))
Comment 20 Kristoffer Grundström 2014-03-10 04:11:26 CET
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
CC: (none) => kristoffer.grundstrom1983
Hardware: i586 => All
Version: Cauldron => 4
Resolution: FIXED => (none)
Whiteboard: 4alpha1 4alpha2 => 4alpha1 4alpha2 mga4

Comment 21 Colin Guthrie 2014-03-10 10:10:31 CET
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
Resolution: (none) => FIXED