Bug#758619: more complete backtrace
On 21/09/14 22:47, Sandro Tosi wrote:
On Thu, Aug 21, 2014 at 10:38 AM, Simon McVittie s...@debian.org wrote:
+gtk.set_interactive (0)
gtk.gdk.threads_init ()
sadly this patch didnt fix the problem, and I can replicate it in a
clean sid chroot. do you have any other suggestions?
The next best ideas I have are:
* ask the gtk2 maintainers to apply upstream commit
fbf38d16bcc26630f0f721d266509f5bc292f606 (attached) to work around
pygtk2 being an example of the wrong code mentioned in that commit;
and/or
* ask the pygtk2 maintainers to stub out the interactive code in
pygtk2, slightly breaking interactive use of pygtk2 but maybe nobody
will actually notice; and/or
* switch reportbug to using Gtk3 via python-gi
I realise that last one is not trivial, but pygtk2 is dead upstream and
gtk2 is not a whole lot better, so it would be a good idea for jessie+1
regardless.
S
From fbf38d16bcc26630f0f721d266509f5bc292f606 Mon Sep 17 00:00:00 2001
From: Emmanuele Bassi eba...@gnome.org
Date: Tue, 26 Aug 2014 12:07:34 +0100
Subject: [PATCH] threads: Do not release the GDK lock if it hasn't been
acquired yet
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Since GLib ⥠2.41, attempting to release an unlocked mutex will abort(),
as it happens on most systems already.
Given the lack of proper documentation on how to use GDK with threads,
there is code in the wild that does:
gdk_threads_init ();
gdk_init ();
...
gtk_main ();
instead of the idiomatically correct:
gdk_threads_init ();
gdk_threads_enter ();
gtk_init ();
...
gtk_main ();
...
gdk_threads_leave ();
Which means that gtk_main() will try to release the GDK lock, and thus
trigger an error from GLib.
we cannot really fix all the wrong code everywhere, and since it does
not cost us anything, we can work around the issue inside GDK itself, by
trying to acquire the GDK lock inside gdk_threads_leave() with
trylock().
https://bugzilla.gnome.org/show_bug.cgi?id=735428
---
gdk/gdk.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/gdk/gdk.c b/gdk/gdk.c
index 0106d8a..f722dbf 100644
--- a/gdk/gdk.c
+++ b/gdk/gdk.c
@@ -434,7 +434,29 @@ static void
gdk_threads_impl_unlock (void)
{
if (gdk_threads_mutex)
-g_mutex_unlock (gdk_threads_mutex);
+{
+ /* we need a trylock() here because trying to unlock a mutex
+ * that hasn't been locked yet is:
+ *
+ * a) not portable
+ * b) fail on GLib ⥠2.41
+ *
+ * trylock() will either succeed because nothing is holding the
+ * GDK mutex, and will be unlocked right afterwards; or it's
+ * going to fail because the mutex is locked already, in which
+ * case we unlock it as expected.
+ *
+ * this is needed in the case somebody called gdk_threads_init()
+ * without calling gdk_threads_enter() before calling gtk_main().
+ * in theory, we could just say that this is undefined behaviour,
+ * but our documentation has always been *less* than explicit as
+ * to what the behaviour should actually be.
+ *
+ * see bug: https://bugzilla.gnome.org/show_bug.cgi?id=735428
+ */
+ g_mutex_trylock (gdk_threads_mutex);
+ g_mutex_unlock (gdk_threads_mutex);
+}
}
/**
--
2.1.0
Bug#758619: more complete backtrace
Hello Simon, On Thu, Aug 21, 2014 at 10:38 AM, Simon McVittie s...@debian.org wrote: --- gtk2_ui.py.orig 2014-08-21 09:28:45.375375786 + +++ gtk2_ui.py 2014-08-21 09:29:02.843495121 + @@ -35,6 +35,7 @@ except: has_spell = False +gtk.set_interactive (0) gtk.gdk.threads_init () import sys sadly this patch didnt fix the problem, and I can replicate it in a clean sid chroot. do you have any other suggestions? Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758619: more complete backtrace
forwarded 758619 https://bugzilla.gnome.org/show_bug.cgi?id=735141 found 758619 glib2.0/2.41.2-1 notfound 758619 glib2.0/2.40.0-4 thanks On 20/08/14 22:50, Eric Valette wrote: Because I use the glib/gtk from experimental I guess. Thanks, yes, it's that. Specifically, this change: https://bugzilla.gnome.org/show_bug.cgi?id=731986 In particular, the abort on incorrect locking is new; the original plan seems to have been for it to be runtime-optional. I've sent this upstream to ask whether runtime-optional is feasible. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758619: more complete backtrace
On 08/21/2014 10:26 AM, Simon McVittie wrote: In particular, the abort on incorrect locking is new; the original plan seems to have been for it to be runtime-optional. I've sent this upstream to ask whether runtime-optional is feasible. Well instead of correcting the symptom, I would prefer to correct the bug itself. If locking mecahnism is hazardous, then it eman beahavior is hazardous and that could lead to other bugs later. Searching for the bug, I saw that, in the past, the very same undefined behavior caused crash instead of and assert. But I have no time (and probably not the gtk/glib basic knowledge) to search for a solution. -- eric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758619: more complete backtrace
On 08/21/2014 10:37 AM, Eric Valette wrote: Searching for the bug, I saw that, in the past, the very same undefined behavior caused crash instead of and assert. http://debian.2.n7.nabble.com/Bug-671785-segfaults-when-running-reportbug-td548240.html meaning the bug is not new and was triggered before evn with the pthread lock mechanism. -- eric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758619: more complete backtrace
# the real bug is #671785 but it's easy to avoid it in reportbug reassign 758619 reportbug tags 758619 + patch thanks On 21/08/14 09:37, Eric Valette wrote: Well instead of correcting the symptom, I would prefer to correct the bug itself. If locking mecahnism is hazardous, then it eman beahavior is hazardous and that could lead to other bugs later. Indeed. I think it's pygtk that is getting this wrong, and as you pointed out in another mail, we have already had a bug to track that, #671785, since 2012. The upstream bug has had no activity since 2012 either, until today. However, reportbug can easily work around it, whereas a solution in pygtk is rather more involved (and might never happen, since pygtk is deprecated upstream); so I think it would be best if the reportbug maintainers apply the one-line workaround, which is to turn off the broken feature with the patch that can be found at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671785#53 (the functional part is reproduced at the end of this mail). Let's use bug number 758619 to track that. I now realise that the steps to reproduce the bug are: * you have either GLib from experimental on Linux, or kFreeBSD, so the locking error is fatal; * you have python-gtk2 and $DISPLAY is set, so reportbug's gtk2 UI module can load; as a side-effect, python-gtk2 registers the faulty PyOS_InputHook implementation; * but you *do not* use the gtk2 UI module, so reportbug calls raw_input(), which results in the PyOS_InputHook being called and with that information, I can reproduce it in an experimental chroot with xvfb-run reportbug reportbug. The patch below fixes it. As much as I'd like to say this is release-critical for python-gtk2, which is also dead upstream, so let's remove it from Debian and tell everyone to use Gtk 3 via pygi, I don't think the maintainers of its 300 reverse dependencies would be very impressed. S --- gtk2_ui.py.orig 2014-08-21 09:28:45.375375786 + +++ gtk2_ui.py 2014-08-21 09:29:02.843495121 + @@ -35,6 +35,7 @@ except: has_spell = False +gtk.set_interactive (0) gtk.gdk.threads_init () import sys -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758619: more complete backtrace
--- gtk2_ui.py.orig 2014-08-21 09:28:45.375375786 + +++ gtk2_ui.py2014-08-21 09:29:02.843495121 + @@ -35,6 +35,7 @@ except: has_spell = False +gtk.set_interactive (0) gtk.gdk.threads_init () import sys I confirm this also fixes the bug for me. Thanks for the support. -- eric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758619: more complete backtrace
gdb --args python /usr/bin/reportbug -b --no-check-available libpulse0 GNU gdb (Debian 7.7.1+dfsg-3) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. Type show configuration for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type help. Type apropos word to search for commands related to word... Reading symbols from python...Reading symbols from /usr/lib/debug//usr/bin/python2.7...done. done. (gdb) run Starting program: /usr/bin/python /usr/bin/reportbug -b --no-check-available libpulse0 [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. *** Welcome to reportbug. Use ? for help at prompts. *** Note: bug reports are publicly archived (including the email address of the submitter). Detected character set: UTF-8 Please change your locale if this is incorrect. Using 'Eric Valette eric2.vale...@orange.com' as your from address. Getting status for libpulse0... Will send report to Debian (per lsb_release). Maintainer for libpulse0 is 'Pulseaudio maintenance team pkg-pulseaudio-de...@lists.alioth.debian.org'. Looking up dependencies of libpulse0... Getting changed configuration files... Briefly describe the problem (max. 100 characters allowed). This will be the bug email subject, so keep the summary as concise as possible, for example: fails to send email or does not start with -q option specified (enter Ctrl+c to exit reportbug without reporting a bug). Attempt to unlock mutex that was not locked Program received signal SIGABRT, Aborted. 0x76f28407 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) thread apply all bt Thread 1 (Thread 0x77fc0700 (LWP 17124)): #0 0x76f28407 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x76f297e8 in __GI_abort () at abort.c:89 #2 0x72cdc85d in g_mutex_unlock_slowpath (mutex=optimized out, prev=optimized out) at /build/glib2.0-MHsCdQ/glib2.0-2.41.2/./glib/gthread-posix.c:1327 #3 0x719f4bbf in IA__gtk_main () at /build/gtk+2.0-zztKf7/gtk+2.0-2.24.24/gtk/gtkmain.c:1256 #4 0x720a7d54 in _loop () at /build/buildd-pygtk_2.24.0-3+b1-amd64-HH_0XF/pygtk-2.24.0/gtk/gtk.override:126 #5 0x74148b21 in readline_until_enter_or_signal (signal=synthetic pointer, prompt=optimized out) at /build/python2.7-WkYSEh/python2.7-2.7.8/Modules/readline.c:996 #6 call_readline (sys_stdin=optimized out, sys_stdout=optimized out, prompt=optimized out) at /build/python2.7-WkYSEh/python2.7-2.7.8/Modules/readline.c:1088 #7 0x0044a06f in PyOS_Readline (sys_stdin=0x772974e0 _IO_2_1_stdin_, sys_stdout=sys_stdout@entry=0x772972a0 _IO_2_1_stdout_, prompt=prompt@entry=0x7434f84c ) at ../Parser/myreadline.c:207 #8 0x004453e2 in builtin_raw_input.lto_priv.1351 (self=optimized out, args=optimized out) at ../Python/bltinmodule.c:2060 #9 0x004c8265 in call_function (oparg=optimized out, pp_stack=optimized out) at ../Python/ceval.c:4021 #10 PyEval_EvalFrameEx () at ../Python/ceval.c:2667 #11 0x004c6ab9 in PyEval_EvalCodeEx () at ../Python/ceval.c:3253 #12 0x004c877c in fast_function (nk=optimized out, na=optimized out, n=optimized out, pp_stack=optimized out, func=optimized out) at ../Python/ceval.c:4117 #13 call_function (oparg=optimized out, pp_stack=optimized out) at ../Python/ceval.c:4042 #14 PyEval_EvalFrameEx () at ../Python/ceval.c:2667 #15 0x004c6ab9 in PyEval_EvalCodeEx () at ../Python/ceval.c:3253 #16 0x004c877c in fast_function (nk=optimized out, na=optimized out, n=optimized out, pp_stack=optimized out, func=optimized out) at ../Python/ceval.c:4117 #17 call_function (oparg=optimized out,
Bug#758619: more complete backtrace
Did you upgrade a package recently that could have triggered this, i.e.
related to Python, GLib, Gtk 2 or reportbug? I would be interested to
know why this is new.
Some analysis below. I think this is probably a pygtk bug, but there is
a workaround that reportbug could use.
On 20/08/14 12:15, VALETTE Eric OLNC/OLPS wrote:
#2 0x72cdc85d in g_mutex_unlock_slowpath (mutex=optimized
out, prev=optimized out)
at
/build/glib2.0-MHsCdQ/glib2.0-2.41.2/./glib/gthread-posix.c:1327
#3 0x719f4bbf in IA__gtk_main () at
/build/gtk+2.0-zztKf7/gtk+2.0-2.24.24/gtk/gtkmain.c:1256
#4 0x720a7d54 in _loop
()
at
/build/buildd-pygtk_2.24.0-3+b1-amd64-HH_0XF/pygtk-2.24.0/gtk/gtk.override:126
#5 0x74148b21 in readline_until_enter_or_signal
(signal=synthetic pointer, prompt=optimized out)
at
/build/python2.7-WkYSEh/python2.7-2.7.8/Modules/readline.c:996
_loop() is pygtk's implementation of PyOS_ImportHook, which takes the
Python GIL and calls gtk_main():
gstate = PyGILState_Ensure();
gtk_main();
PyGILState_Release(gstate);
gtk_main() releases the GDK mutex before calling g_main_loop_run(), and
reacquires it afterwards:
if (g_main_loop_is_running (main_loops-data))
{
GDK_THREADS_LEAVE ();
g_main_loop_run (loop);
GDK_THREADS_ENTER ();
gdk_flush ();
}
which means it is not safe to call gtk_main() without holding the GDK
mutex (it is documented that only the thread holding the GDK mutex can
safely call Gtk functions, so that seems reasonable).
However, pygtk doing this in an input hook seems wrong, because I don't
see anything that would guarantee that all invocations of Python's
readline wrapper will be done from a thread that currently holds the GDK
mutex. There is also nothing to say that invocations of the readline
wrapper *won't* be done from a thread that holds the GDK mutex; so there
doesn't seem to be any way this can be done safely?
I don't know what code in reportbug is triggering this hook. One
possible solution would be for reportbug to call gtk.set_interactive(0)
to avoid registering this hook, since the hook's intended use seems to
be for the interactive Python prompt rather than real applications, so
reportbug probably gets nothing useful from it.
pygtk is deprecated upstream, and python-gi does not have this hook, so
I think it's rather unlikely that this hook will be fixed in pygtk,
except possibly via deletion.
I don't think GLib is really doing anything wrong by crashing here: the
C code in pygtk is asking to unlock a mutex that is not actually locked,
which is a symptom of doing locking in a way that can't possibly be
reliable, so I would be inclined to put it in the category of undefined
behaviour.
The only way I can think of to make this hook reliable would be for
pygtk to use gdk_threads_set_lock_functions() before gdk_threads_init(),
to replace gdk_threads_enter and gdk_threads_leave with functions that
use a recursive mutex:
GRecMutex rmutex;
init()
{
gdk_threads_set_lock_functions (enter, leave);
gdk_threads_init ();
}
enter()
{
g_rec_mutex_lock (rmutex);
}
leave()
{
g_rec_mutex_unlock (rmutex);
}
and then make _loop() ensure that the rmutex is locked while it calls
gtk_main(). However, it would be necessary to be rather careful about
lock acquisition order between rmutex and the GIL, to avoid deadlocking
between one thread that is holding rmutex and wants the GIL, and another
thread that is holding the GIL and wants rmutex; so this plan is
probably flawed too.
Regards,
S
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758619: more complete backtrace
On 20/08/2014 22:46, Simon McVittie wrote: Did you upgrade a package recently that could have triggered this, i.e. related to Python, GLib, Gtk 2 or reportbug? I would be interested to know why this is new. Because I use the glib/gtk from experimental I guess. And you could have noticed it by reading the other info I have been requested to report. --eric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
