GNOME Bugzilla – Bug 567396
playbin2: DECODE_BIN_LOCK occasionally called twice within one thread on playback start
Last modified: 2009-02-25 09:14:26 UTC
On some occasions, playbin2 will deadlock when transitioning from NULL (or READY) to PLAYING. I have found a particular FLAC file which will trigger this behavior every time. It appears that this behavior is not exhibited from the gst-launch command line, but a simple script will be attached that demonstrates the error. Most of my music is in FLAC format; while I recall having seen this behavior when playing MP3s, I haven't been able to reproduce it recently, so I'm not positive where the fault lies. However, the file plays fine from a playbin classic, which is a pretty good sign that playbin2 is at least partly to blame. The file is copyrighted and 29MB. I won't post it on the tracker unless asked to do so. Anyone can contact me directly to get a link to an HTTP download instead. Thanks for your help. Also, feel free to trademark "playbin classic".
I ran the script one more time just before submitting it. Naturally, the script worked fine, demonstrating no problems. Thinking it was more than just my computer trying to make me look like a fool, I poked around a bit. The only thing that had changed between previous executions and this one was the environment; when it worked, GST_DEBUG was unset. It appears that when GST_DEBUG="GST_STATES:3" or higher, or the equivalent is done using gst_debug_set_default_threshold or similar, playbin2 will occasionally hang. The file I have still reproduces this behavior 100% of the time, as long as the debug condition is met, but others do not always trigger it.
Created attachment 126225 [details] Demonstrates the bug. Run with GST_DEBUG set as described in comments.
can you run this on the 100% failing file: GST_DEBUG=GST_STATES:3,*decodebin*:5,*play*:5 gst-launch playbin2 uri=file:///path/to/file.flac >debug.log 2>&1 then gzip and attach the debug.log file.
Created attachment 126834 [details] TGZ of debug output and all threads backtrace Attached, with an all-threads backtrace from gdb included just for kicks. The bug is reliably induced on my system only when the delays of actually printing output are felt by each thread; piping debug info straight to a file upset the timing. Using 'tee', which seems to have synchronous input and output, allowed for output to be captured and timing to still work right.
__tim on the channel suggested that a poke might be beneficial in getting this resolved, so here it is. Another rename, as well, which more accurately reflects the problem. I did a bit of digging and it seems that most of these lockups are being caused by application of g_mutex_lock twice in one thread. According to the GLib reference manual: GMutex is neither guaranteed to be recursive nor to be non-recursive, i.e. a thread could deadlock while calling g_mutex_lock(), if it already has locked mutex. Use GStaticRecMutex, if you need recursive mutexes. --- http://library.gnome.org/devel/glib/2.18/glib-Threads.html#g-mutex-lock I will test and, if successful, post a patch which resolves this by swapping for GStaticRecMutex. It should be noted that there's a similar error which results in a deadlock upon disposing of a finished track's elements during a gapless transition. If the patch is unsuccessful, I'll create a separate bug for that.
In general, I think people prefer using non-recursive mutexes. But that might be because GStaticRecMutex hasn't been around very long.
this file is a flac file with an id3 tag in the beginning. It seems to trigger some weird no-more-pads from the main thread while a pad block is happening in the streaming thread.
managed to reproduce with a flac/id3 tag file I made and a carfully added g_usleep().
This should fix it: commit dbfc80cd6c4de3b91fd9c78beec855e90cc50bc2 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Wed Feb 25 10:08:29 2009 +0100 Release the group lock when setting states Release the group lock while we perform the state changes on the uridecodebins because that might trigger callbacks that we need to handle with the group lock taken. Avoids a possible deadly embrace in some id3/flac files. Fixes #567396.