Do.exe crashed with SIGABRT in __GI_raise()

Bug #1344386 reported by Wellington Torrejais da Silva on 2014-07-18
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Do
Undecided
Unassigned
glib2.0 (Ubuntu)
Undecided
Unassigned
gnome-do (Ubuntu)
Undecided
Chris Halse Rogers

Bug Description

Do.exe crashed with SIGABRT in __GI_raise()

ProblemType: Crash
DistroRelease: Ubuntu 14.10
Package: gnome-do 0.9-1build1
ProcVersionSignature: Ubuntu 3.13.0-32.57-generic 3.13.11.4
Uname: Linux 3.13.0-32-generic x86_64
ApportVersion: 2.14.4-0ubuntu2
Architecture: amd64
CurrentDesktop: GNOME
Date: Fri Jul 18 17:47:01 2014
ExecutablePath: /usr/lib/gnome-do/Do.exe
InstallationDate: Installed on 2014-05-16 (63 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
InterpreterPath: /usr/bin/mono-sgen
ProcCmdline: /usr/bin/cli /usr/lib/gnome-do/Do.exe
Signal: 6
SourcePackage: gnome-do
StacktraceTop:
 __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
 __GI_abort () at abort.c:89
 ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
 gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
 ?? ()
Title: Do.exe crashed with SIGABRT in __GI_raise()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

tags: removed: need-amd64-retrace
information type: Private → Public
Launchpad Janitor (janitor) wrote :

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

Changed in gnome-do (Ubuntu):
status: New → Confirmed
Barry Warsaw (barry) wrote :

By process of elimination (i.e. bisecting apt-get installs of all the dist-upgrade upgrading packages), I've narrowed this down to the following binary packages: libglib2.0-0 libglib2.0-bin libglib2.0-dev all part of the glib2.0 source package, version 2.41.2-1. In all likelihood it's the libglib2.0-0 (but harder to tell since all three must be upgraded at the same time).

I've also confirmed that no change rebuilds of mono and gnome-do do *not* fix the problem. Something deeper has changed in the latest glib2.0 package to break gnome-do at least, and perhaps the entire mono runtime.

Next I'll try to compare against Debian versions to see if anything out of sync needs updating.

Barry Warsaw (barry) wrote :

This seems to be the best I can manage for a traceback. Note that I had to manually hack /usr/lib/debug/usr/bin/mono-sgen-gdb.py to be Python 3 compatible (will file a separate bug on that).

There are still some undefined symbols, but I can't suss out which packages are missing, and apport does not seem to want to cooperate to help me. Please let me know if there's more I information you want me to extract. OTOH, it's completely reproducible on utopic. Install gnome-do and then invoke that from the command line.

Chris Halse Rogers (raof) wrote :

Hm, thanks.

This seems to be triggered by a change to GMutex in glib 2.14.2 (good work on the bugfix release, guys ☺). I'll see if I can hunt down what's releasing the mutex glib thinks isn't held. I used to be able to get decent backtraces out of Mono!

Changed in gnome-do (Ubuntu):
assignee: nobody → Chris Halse Rogers (raof)
desrt (desrt) wrote :

GLib completely changed the implementation of GMutex from being based on POSIX primatives to being based on a home-grown solution that is substantially faster (and with room for further improvements).

This caused deadlocks/crashes in some Vala programs, and I wonder if the same thing is going on with Mono. See this bug: https://bugzilla.gnome.org/show_bug.cgi?id=733500

Iain Lane (laney) wrote :

On stderr, the following is printed

  Attempt to unlock mutex that was not locked

this is an abort() within glib - it's what RAOF alluded to in comment #5.

desrt (desrt) wrote :

The new mutex implementation detects the (error) case when you try to unlock a mutex that is not locked.

Callers are supposed to acquire the Gtk lock before calling gtk_main() and I guess gnome-do isn't doing that...

POSIX silently ignores this...

desrt (desrt) wrote :

Invalid for glib since the bug is confirmed as being in gnome-do (not acquiring the lock before gtk_main).

Changed in glib2.0 (Ubuntu):
status: New → Invalid
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-do - 0.95.1-1ubuntu1

---------------
gnome-do (0.95.1-1ubuntu1) utopic; urgency=medium

  * Correctly call Gdk.Threads.Enter() before entering the GTK mainloop.
    (LP: #1344386)
 -- Christopher James Halse Rogers <email address hidden> Wed, 20 Aug 2014 11:01:39 +1000

Changed in gnome-do (Ubuntu):
status: Confirmed → Fix Released
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.