** Branch linked: lp:debian/gnome-do
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1344386
Title:
Do.exe crashed with SIGABRT in __GI_raise()
Status in Do:
New
Status
** Branch linked: lp:ubuntu/gnome-do
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1344386
Title:
Do.exe crashed with SIGABRT in __GI_raise()
Status in Do:
New
Status
** Also affects: do
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1344386
Title:
Do.exe crashed with SIGABRT in __GI_raise()
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 RogersWed, 20 Aug 2014
11:01:39 +1000
** Cha
** Branch linked: lp:ubuntu/utopic-proposed/gnome-do
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1344386
Title:
Do.exe crashed with SIGABRT in __GI_raise()
Status in “
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
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to glib2.0
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...
--
You received this bug notification because y
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.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to glib2.0 in Ubuntu.
h
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 w
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)
Assig
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 n
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
12 matches
Mail list logo
