GNOME Bugzilla – Bug 690740
set_interactive(1) (default) makes flawed locking assumptions and breaks with GLib 2.41 or on kFreeBSD
Last modified: 2018-08-17 13:40:06 UTC
As far as I can tell, the following short pygtk program complies with the rules about threads from the pygtk faq (http://faq.pygtk.org/index.py?req=show&file=faq20.001.htp) and with the caveat about calling gbjects.threads_init() from bug #461551. However, under Debian GNU/Linux amd64 testing (python-gtk2 2.24.0-3), it results in a helgrind diagnostic, and under Debian GNU/kFreeBSD amd64 testing (python-gtk2 2.24.0-3) it results in a segfault. #!/usr/bin/python import gobject gobject.threads_init() import gtk gtk.gdk.threads_init() raw_input("hit enter if this did not crash >") $ valgrind --tool=helgrind python threadbug.py ... Thread #1 unlocked a not-locked lock at 0xD48E7E0 at 0x4C2BF9D: pthread_mutex_unlock (hg_intercepts.c:609) by 0x71C4450: g_mutex_unlock (gthread-posix.c:227) by 0x829078E: gtk_main (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.10) by 0x7E46C23: _loop (gtk.override:126) by 0x486172: my_fgets.3695.2566 (in /usr/bin/python2.7) by 0x486258: PyOS_StdioReadline (in /usr/bin/python2.7) by 0x48655F: PyOS_Readline (in /usr/bin/python2.7) by 0x562F91: builtin_raw_input.32661 (in /usr/bin/python2.7) by 0x4EAA3A: PyEval_EvalFrameEx (in /usr/bin/python2.7) by 0x4F1DAF: PyEval_EvalCodeEx (in /usr/bin/python2.7) by 0x4D980C: PyRun_FileExFlags (in /usr/bin/python2.7) by 0x4D9A95: PyRun_SimpleFileExFlags (in /usr/bin/python2.7) Lock at 0xD48E7E0 was first observed at 0x4C2B79A: pthread_mutex_init (hg_intercepts.c:429) by 0x71C4146: g_mutex_impl_new (gthread-posix.c:99) by 0x71C43E8: g_mutex_init (gthread-posix.c:167) by 0x715CC95: g_mutex_new (gthread-deprecated.c:1473) by 0x87B3738: gdk_threads_init (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.10) by 0x7E7BEAE: _wrap_gdk_threads_init (gdk.override:128) by 0x4EB52B: PyEval_EvalFrameEx (in /usr/bin/python2.7) by 0x4F1DAF: PyEval_EvalCodeEx (in /usr/bin/python2.7) by 0x4D980C: PyRun_FileExFlags (in /usr/bin/python2.7) by 0x4D9A95: PyRun_SimpleFileExFlags (in /usr/bin/python2.7) by 0x4DA39D: Py_Main (in /usr/bin/python2.7) by 0x5F4EEAC: (below main) (libc-start.c:228) ... A similar problem exists if the last line is a call to gtk.main() instead of to raw_input(), which appears to be in line with the pygtk faq recommendation but is possibly bad advice which simply needs to be fixed. Downstream, this problem has led to a kfreebsd-amd64 crashing bug in debian's 'reportbug' python package (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671785)--the program given above is a distilled version of what's going on in reportbug.
*** Bug 735142 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > Downstream, this problem has led to a kfreebsd-amd64 crashing bug in debian's > 'reportbug' python package > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671785)--the program given > above is a distilled version of what's going on in reportbug. Since GLib 2.41, unlocking an unlocked mutex is also fatal on Linux. More analysis on Bug #735142.
Fixing Bug #735428 might have worked around this. (But pygtk is still wrong, IMO.)
(In reply to comment #3) > Fixing Bug #735428 might have worked around this. (But pygtk is still wrong, > IMO.) Agreed that pygtk is probably wrong. Also note (AFAICT) pygtk does not have a maintainer and has not seen a release since 2011.
pygtk is not under active development anymore and had its last code changes in 2013. Its codebase has been archived: https://gitlab.gnome.org/Archive/pygtk/commits/master PyGObject at https://gitlab.gnome.org/GNOME/pygobject is its successor. See https://pygobject.readthedocs.io/en/latest/guide/porting.html for porting info. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Feel free to open a task in GNOME Gitlab if the issue described in this task still applies to a recent version of PyGObject. Thanks!