GNOME Bugzilla – Bug 673708
using playbin2 with "fd://" URIs randomly hangs or crashes
Last modified: 2012-04-17 08:09:55 UTC
Created attachment 211559 [details] Example code and media file The setup is simple: 1. create a playbin2. 2. open an audio file 3. set playbin2's URI to `fd://<fd of opened audio file>' 4. when the `about-to-finish' message is received; open another audio file and set the URI to `fd://<fd of opened audio file>' 5. when the `playbin2-stream-changed' message is received; close the previous filedescriptor One would expect the audio file to be played over and over again without gap. However, one of the following problems occur: 1. Very common: After a few playbacks (2 or 3 times are common, but 4 - 8 times also occur), GStreamer hangs. After the URI is changed the current audio file is played successfully to the end, but the new audio file is not started. ( calls to for instance get_property('uri') hang afterwards; the process is using ~5% CPU ) 2. Occasionally (1/10): the process segfaults or exits without any specific error message. Attached is a .tar with an example Python script of the setup along with an example OGG.
Created attachment 211561 [details] Example Python and C code and media file Also added example code in C.
The C code compiles on my Arch Linux installation with gstreamer 0.10.35 The program hangs after two or three playbacks.
The problem does *not* occur on GStreamer 0.10.32.
The problem does *not* occur on GStreamer 0.10.32 with base plugins 0.10.32 and good plugins 0.10.28. The problem does occur on GStreamer 0.10.33 with base plugins 0.10.33 and good plugins 0.10.29.
The problem does *not* occur on GStreamer 0.10.33 with base plugins 0.10.32 and good plugins 0.10.28. The problem does occur on GStreamer 0.10.33 with base plugins 0.10.33 and good plugins 0.10.28. It appears the problem is introduced in base-plugins from 0.10.32 to 0.10.33.
I bisected and I ended up at this commit: bas@vinnana ~/src/gst-plugins-base $ git bisect good 555e33800867d68bfed0e27546448e738acabf35 is the first bad commit commit 555e33800867d68bfed0e27546448e738acabf35 Author: Akihiro Tsukada <tskd2@yahoo.co.jp> Date: Tue Feb 15 17:24:28 2011 +0100 playbin2: Fix handling of non-raw custom sinks When autoplugging elements in decodebin2, check if the caps are supported by one of the sink before continuing autoplugging. Fixes bug #642174.
The bisect log: # bad: [519f35059938263fbeaf02f9f13acbbd633d46d6] Release 0.10.33 # good: [c2e0ec6d0bef44827476d96ee9e5ae92dec8be46] Release 0.10.32 git bisect start 'RELEASE-0.10.33' 'RELEASE-0.10.32' # bad: [a0ff13217a1da3693533a4ca7854ed28a71701f8] playbin2: Always prefer the custom set sink and also set it back to NULL in all cases. git bisect bad a0ff13217a1da3693533a4ca7854ed28a71701f8 # bad: [0ed72c29596338e53079e978c4af7bba5a859baf] video: Add ARGB64 and AYUV64 git bisect bad 0ed72c29596338e53079e978c4af7bba5a859baf # good: [54c19ba6def4f9cead7e18a893c981e425f9405c] oggmux: free stream map caps when done git bisect good 54c19ba6def4f9cead7e18a893c981e425f9405c # bad: [15e23414d369fa762c62a701d6480b0dee0a2ca2] oggparse: better detection of delta unit flag git bisect bad 15e23414d369fa762c62a701d6480b0dee0a2ca2 # good: [46f3e7c6fd9148677e97e01c5a29f07f59a132b3] theoraenc: Don't reset the video quality setting the bitrate git bisect good 46f3e7c6fd9148677e97e01c5a29f07f59a132b3 # skip: [c201ff3de3ce36dfc658b13dc4f637c923e3a01d] discoverer: improve logging (and reindent) git bisect skip c201ff3de3ce36dfc658b13dc4f637c923e3a01d # bad: [d467eb708af0d4b36f8b8d64dc20959a5033e79a] Set the theoraenc speed-level property from libtheora's defaults. git bisect bad d467eb708af0d4b36f8b8d64dc20959a5033e79a # bad: [140dca43f35d5438d8c5300bd150e9fb69beea59] playbin2: Optimize autoplug-continue handler a bit git bisect bad 140dca43f35d5438d8c5300bd150e9fb69beea59 # bad: [555e33800867d68bfed0e27546448e738acabf35] playbin2: Fix handling of non-raw custom sinks git bisect bad 555e33800867d68bfed0e27546448e738acabf35 # good: [fbf972979561676507d6083ef16c986df1394cd7] decodebin2: Don't leak elements that fail to go to PAUSED after being autoplugged git bisect good fbf972979561676507d6083ef16c986df1394cd7
Created attachment 212017 [details] [review] Workaround patch which fixes the problem in 0.10 The attached patch reverts most of the linked commit which introduces the bug. With this patch, applied against gst-plugins-base 0.10.35, the problem in this bug report is gone. I don't recommend applying this patch as-is, as it probably breaks the original issue solved by this patch. It is only meant to show that the bug is still caused by the code originally added in 555e33800867d68bfed0e27546448e738acabf35.
Created attachment 212151 [details] [review] Patch to fix the dead lock [PATCH] remove the unnecessary PLAYBIN_LOCK around autoplug_continue_cb() I think the LOCK caused this bug. When the play out of the old URI is ending, activate_group() is called from the thread for the old URI, with the PLAYBIN_LOCK held. activate_group() sets the state of the child uridecodebin for the new URI to PAUSED state and wait for its completion without releasing the LOCK. The awakened uridecodebin invokes another thread which requires the PLAYBIN_LOCK to continue auto-plugging, resulting in a dead lock. The LOCK was added to protect the change of playbin->{audio-,video-,text-}sink properties, but actually it was useless as the properties were not proteced during the whole lifetime of the group, and they are now copied to the corresponding group properties in the group activation (commit a0ff13217a).
Thanks for the patch but please attach it in "git format-patch" format in the future :) commit 77db9a887c201ec248e8d070000619d1e45c7943 Author: Akihiro Tsukada <tskd2@yahoo.co.jp> Date: Tue Apr 17 09:54:09 2012 +0200 playbin2: Don't hold the playbin lock in the autoplug-continue callback It's not necessary there as the group lock already protects everything we access here and causes deadlocks in some cases. Fixes bug #673708.
So does this fix the 'or crashes' bit as well?