After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 567396 - playbin2: DECODE_BIN_LOCK occasionally called twice within one thread on playback start
playbin2: DECODE_BIN_LOCK occasionally called twice within one thread on play...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: 0.10.23
Assigned To: Wim Taymans
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-01-11 18:17 UTC by Steven Robertson
Modified: 2009-02-25 09:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Demonstrates the bug. Run with GST_DEBUG set as described in comments. (743 bytes, text/x-python)
2009-01-11 18:32 UTC, Steven Robertson
Details
TGZ of debug output and all threads backtrace (6.33 KB, application/x-compressed-tar)
2009-01-20 13:28 UTC, Steven Robertson
Details

Description Steven Robertson 2009-01-11 18:17:45 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".
Comment 1 Steven Robertson 2009-01-11 18:31:19 UTC
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.
Comment 2 Steven Robertson 2009-01-11 18:32:32 UTC
Created attachment 126225 [details]
Demonstrates the bug.  Run with GST_DEBUG set as described in comments.
Comment 3 Wim Taymans 2009-01-20 11:25:54 UTC
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.
Comment 4 Steven Robertson 2009-01-20 13:28:33 UTC
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.
Comment 5 Steven Robertson 2009-02-11 02:49:06 UTC
__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.
Comment 6 David Schleef 2009-02-11 02:54:48 UTC
In general, I think people prefer using non-recursive mutexes.  But that might be because GStaticRecMutex hasn't been around very long.
Comment 7 Wim Taymans 2009-02-24 11:46:20 UTC
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.
Comment 8 Wim Taymans 2009-02-24 17:03:54 UTC
managed to reproduce with a flac/id3 tag file I made and a carfully added g_usleep().
Comment 9 Wim Taymans 2009-02-25 09:13:33 UTC
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.