Do.exe crashed with SIGABRT in __GI_raise()

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

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.

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.

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!

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

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.

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...

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

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