GNOME Bugzilla – Bug 710447
Segfault with pygobject introspection and GStreamer
Last modified: 2013-11-11 13:57:30 UTC
I'm observing a segmentation fault when using python-gi 3.10 and GStreamer 1.2 with decodebin. I'm not certain this is a bug in pygobject, it might just as well be an issue with GStreamer or just the interaction of the two via introspection. I'm reporting this here in the hope that someone else can figure out the hard details. The crash happens reproducibly both on Ubuntu 13.10 and Fedora 20 Alpha 4, both of which have pygobject 3.10 and GStreamer 1.2. The same code worked on Ubuntu 13.04, which uses pygobject 3.8 and GStreamer 1.0. The input file does not matter, I tried with several MP3 and Ogg Vorbis files. Judging by the backtrace, the crash seems to have something to do with threading. In addition, I did at one point get a "Fatal Python error: This thread state must be current when releasing" message, but I never managed to reproduce it, so it might not have anything to do with the problem at hand. I've attached a gdb backtrace, a hopefully minimal example that causes the crash as well as a slightly different version of the example that doesn't crash [1]. The actual software that I originally encountered the crash with is at [2]; the crashing example is very much adapted from that. [1] https://gist.github.com/fkrull/7039994 [2] https://bitbucket.org/fk/rgain
48e52210ece0e144b4c959e773ea542a912358e7 is the first bad commit commit 48e52210ece0e144b4c959e773ea542a912358e7 Author: Simon Feltman <sfeltman@src.gnome.org> Date: Thu Mar 7 00:26:37 2013 -0800 Deprecate GLib and GObject threads_init Remove a handful of Python threading related helper functions from pyglib and pygobject. The binding internals required GLib.threads_init to be called for PyGObject to work with Python threads. This was removed as it should not be a requirement. Using the Python threading module already initializes threading for us (PyEval_InitThreads). https://bugzilla.gnome.org/show_bug.cgi?id=686914 :040000 040000 399364115a250dfc78dcc84216314670fbcec0a1 1254e56e99faa7d901d900633392cdf9890ad955 M gi
If you're suggesting that the call to GObject.threads_init() is the issue: I did stumble upon that bug report, but removing that call didn't change anything. I just tried adding an 'import threading' (which that change seems to suggest) but that didn't help either.
No idea, I just bisected it to show that it's a bug in pygobject.
Christoph, Thanks for bisecting that. Felix, As a workaround you can do this at the top of your program: ##### import threading threading.Thread(target=lambda: None).start() ##### It looks like we still need some form of threads_init after all. Other GI libs using non-Python threads that interact with Python callbacks need PyEval_InitThreads() to be called (this is what the hack above does).
Pushed a fix to 3.10 branch.
Cherry-picked patch from 3.10 but I kept the deprecation message (with updates). The following fix has been pushed: 0c308de Add threads_init back as a requirement for non-Python threaded repos
Created attachment 257679 [details] [review] Add threads_init back as a requirement for non-Python threaded repos Re-add a "threads_init" function to gi for explicit intialization of Python threading support. This was marked as deprecated in the previous cycle because using Python threads already initializes everything. However, we still need an explicit initalization when using repositories with non-Python threads which may interact with Python callbacks (GStreamer).
Please have a look at bug 709223 which now removed the threads_init() call again (so compared to 3.10.1 nothing actually changes in the API).