gnome-shell crashed with SIGABRT in g_thread_abort()

Bug #1284017 reported by two clix on 2014-02-24
74
This bug affects 8 people
Affects Status Importance Assigned to Milestone
dconf
Invalid
Critical
d-conf (Ubuntu)
Invalid
Critical

Bug Description

gnome-shell crashed on system restart.

ProblemType: Crash
DistroRelease: Ubuntu 14.04
Package: gnome-shell 3.10.4-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-11.31-generic 3.13.3
Uname: Linux 3.13.0-11-generic x86_64
ApportVersion: 2.13.2-0ubuntu5
Architecture: amd64
CurrentDesktop: GNOME
Date: Mon Feb 24 12:24:40 2014
DisplayManager: gdm
ExecutablePath: /usr/bin/gnome-shell
GsettingsChanges:

InstallationDate: Installed on 2014-02-09 (14 days ago)
InstallationMedia: Ubuntu-GNOME 14.04 "Trusty Tahr" - Alpha amd64 (20140121.1)
ProcCmdline: gnome-shell --mode=gdm
ProcEnviron:
 SHELL=/bin/false
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
Signal: 6
SourcePackage: gnome-shell
StacktraceTop:
 ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
 g_mutex_lock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
 ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
 ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
 ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
Title: gnome-shell crashed with SIGABRT in g_mutex_lock()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

two clix (twoclixs) wrote :

StacktraceTop:
 g_thread_abort (status=<optimized out>, function=function@entry=0x7f3363775a0e "pthread_mutex_lock") at /build/buildd/glib2.0-2.39.90/./glib/gthread-posix.c:74
 g_mutex_lock (mutex=mutex@entry=0x3bf8e58) at /build/buildd/glib2.0-2.39.90/./glib/gthread-posix.c:209
 dconf_engine_acquire_sources (engine=engine@entry=0x3bf8e40) at dconf-engine.c:200
 dconf_engine_get_state (engine=0x3bf8e40) at dconf-engine.c:314
 dconf_engine_watch_established (engine=0x3bf8e40, handle=0x3bf2cc0, reply=<optimized out>, error=<optimized out>) at dconf-engine.c:778

Changed in gnome-shell (Ubuntu):
importance: Undecided → Medium
summary: - gnome-shell crashed with SIGABRT in g_mutex_lock()
+ gnome-shell crashed with SIGABRT in g_thread_abort()
tags: removed: need-amd64-retrace

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

information type: Private Security → Public

Thanks so much for your time too, your info is well appreciated

On Mon, Feb 24, 2014 at 10:48 PM, Seth Arnold <email address hidden>wrote:

> Thanks for taking the time to report this bug and helping to make Ubuntu
> better. We appreciate the difficulties you are facing, but this appears
> to be a "regular" (non-security) bug. I have unmarked it as a security
> issue since this bug does not show evidence of allowing attackers to
> cross privilege boundaries nor directly cause loss of data/privacy.
> Please feel free to report any other bugs you may find.
>
> ** Information type changed from Private Security to Public
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1284017
>
> Title:
> gnome-shell crashed with SIGABRT in g_thread_abort()
>
> Status in "gnome-shell" package in Ubuntu:
> New
>
> Bug description:
> gnome-shell crashed on system restart.
>
> ProblemType: Crash
> DistroRelease: Ubuntu 14.04
> Package: gnome-shell 3.10.4-0ubuntu1
> ProcVersionSignature: Ubuntu 3.13.0-11.31-generic 3.13.3
> Uname: Linux 3.13.0-11-generic x86_64
> ApportVersion: 2.13.2-0ubuntu5
> Architecture: amd64
> CurrentDesktop: GNOME
> Date: Mon Feb 24 12:24:40 2014
> DisplayManager: gdm
> ExecutablePath: /usr/bin/gnome-shell
> GsettingsChanges:
>
> InstallationDate: Installed on 2014-02-09 (14 days ago)
> InstallationMedia: Ubuntu-GNOME 14.04 "Trusty Tahr" - Alpha amd64
> (20140121.1)
> ProcCmdline: gnome-shell --mode=gdm
> ProcEnviron:
> SHELL=/bin/false
> PATH=(custom, no user)
> XDG_RUNTIME_DIR=<set>
> LANG=en_US.UTF-8
> Signal: 6
> SourcePackage: gnome-shell
> StacktraceTop:
> ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> g_mutex_lock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
> ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
> ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
> Title: gnome-shell crashed with SIGABRT in g_mutex_lock()
> UpgradeStatus: No upgrade log present (probably fresh install)
> UserGroups:
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1284017/+subscriptions
>

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-shell (Ubuntu):
status: New → Confirmed
Erick Brunzell (lbsolost) wrote :

Is this bug and my duplicate bug #1285033 possibly related to bug #1284983?

Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1284017

tags: added: iso-testing
Erick Brunzell (lbsolost) wrote :

Regarding my duplicate bug #1285033 I have encountered this with both Ubuntu GNOME 20140226 i386 and amd64.

In both instances I was using manual partitioning (aka: Something else) with pre-existing partitions, then just selecting which partition to use for/. Perhaps importantly this test box has two drives, each with a swap partition, so I would also select "change" and then select "do not use this partition" on the swap partition I did not wish to use. I did allow grub to install to /dev/sda.

Of great importance is that this only happens if I choose NOT to auto-login! But it's not consistently reproducible so I need to hack away and see if I can find a truly 100% reproducible test-case.

What happens is that gdm seems to take a long time to appear (may mislead a user to think the system is frozen), then when it does load and you login apport auto reports this bug.

Tim (darkxst) wrote :

desrt, any ideas on this one? seemingly gnome-shell is aborting deep inside dconf, then respawning and working correctly the second time

Erick Brunzell (lbsolost) wrote :

I think I've done a bad job of describing this :^(

My duplicate bug #1285033 resulted from the first boot after installation, subsequent boots seem to be OK.

The partitioning scheme or installation method seems to make little difference as I've now encountered this using manual partitioning, entire disc install, and upgrading via live DVD on a bare-metal 80GB drive using this hardware:

Intel Atom CPU 230 @ 1.60GHz
Intel 82945G/GZ Integrated Graphics Controller (rev 02)
Intel N10/ICH 7 Family High Definition Audio Controller (rev 01)
Realtek RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)
2GB DDR2 RAM

The one constant is that auto-login must NOT be chosen during installation. Installations where auto-login is chosen do not seem to be effected.

But the behavior is not 100% reproducible so multiple test installs may be required to reproduce this bug.

So if I were to redefine what I'm seeing I'd say, "Sometimes after performing an Ubuntu GNOME installation without choosing to auto-login gdm may take a long time to appear on the initial boot which may lead a user to think the boot process is frozen but gdm will eventually appear and then apport may auto-generate this bug".

I realize that "sometimes" and "may" stink in a definition but it's true in this case. The behavior is just not consistent.

@ two clix,

Does that definition make sense to you?

Or was your experience something altogether different?

Tim (darkxst) wrote :

Lance, the delay is most likely because gnome-shell crashes, and then respawns, so its really loading twice. The actual crash (which is really just an abort) is quite low level, so I am surprised that auto-login makes any difference, Either way your description was fine.... but lets wait on desrt to comment on this, the backtrace is just a little too multi-threaded for me to really make sense of (and I certainly don't understand how a g_mutex_lock, can cause an abort, it should either deadlock if something else has the lock or do nothing if things are not initialised properly).

Changed in gnome-shell:
importance: Unknown → Critical
status: Unknown → New
affects: gnome-shell → dconf (Ubuntu)
affects: gnome-shell (Ubuntu) → dconf
Vlad Orlov (monsta) on 2015-02-15
Changed in dconf:
importance: Medium → Unknown
status: Confirmed → Unknown
affects: dconf (Ubuntu) → d-conf (Ubuntu)
Allison Lortie (desrt) wrote :

It's worth noting that this bug can no longer occur as it is described here -- g_mutex_lock() has been rewritten and the new version doesn't abort.

That said, the underlying issue that was causing the misuse of a mutex could very well still exist... Unfortunately, it's very difficult to guess what that may be, at this point.

Allison Lortie (desrt) wrote :

In fact, I think this was fixed a year ago already:

  https://bugzilla.gnome.org/show_bug.cgi?id=724929

Did anyone see this in newer Ubuntu releases (ie: the released version of trusty or later)?

Changed in d-conf (Ubuntu):
status: New → Invalid
Changed in dconf:
importance: Unknown → Critical
status: Unknown → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.