** Branch linked: lp:debian/gnome-do
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1344386
Title:
Do.exe crashed with SIGABRT in __GI_raise()
To manage notifications about this b
** Branch linked: lp:ubuntu/gnome-do
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1344386
Title:
Do.exe crashed with SIGABRT in __GI_raise()
To manage notifications about this b
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
** Also affects: do
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1344386
Title:
Do.exe crashed with SIGABRT in __GI_raise()
To manage
** Branch linked: lp:ubuntu/utopic-proposed/gnome-do
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1344386
Title:
Do.exe crashed with SIGABRT in __GI_raise()
To manage notificati
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
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
Desktop Bugs, which is subscribed to glib2.0 in Ubuntu
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
Desktop Bugs, which is subscribed to glib2.0 in Ubuntu.
https://bu
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
