GNOME Bugzilla – Bug 736969
queue2: dead lock when buffering
Last modified: 2014-11-23 14:12:16 UTC
Created attachment 286620 [details] GST_DEBUG=5 The fix for bug #727255 seems to have introduced a regression when playing buffered stream. Here is a log when trying to play from a DLNA server. gst-launch is stuck at "Buffering 10%". It doesn't happen all the time so I guess there is a race or something but after lots of testing and bisecting I'm pretty confident that the regression has been introduced with http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=a2122f04ec6305a1393e73eb8e7fccb291f36ccb
+ Trace 234111
Thread 4 (Thread 0x7fb8dfdd4700 (LWP 22737))
Created attachment 286625 [details] log with core updated to master
From a quick glance it seems the same case as with multiqueue -> posting buffering messages holding the lock.
Created attachment 286633 [details] [review] queue2: do not post buffering messages holding the lock Assembled this patch quickly here from the multiqueue one. Still going to do a better review of it myself. But could be tested already by the reporter. Thanks
Yep this patches does fix my bug; thanks!
Pushed to master. commit ecf479e3d1885c41208ca0df7c7d4b6d3e2d2af7 Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Fri Sep 19 12:02:46 2014 -0300 queue2: do not post buffering messages holding the lock It might cause deadlocks to post messages while holding the queue2 lock. To avoid this a new boolean flag is set whenever a new buffering percent is found. The message is posted after the lock is released. To make sure the buffering messages are posted in the right order, messages are posted holding another lock. This prevents 2 threads trying to post messages at the same time. https://bugzilla.gnome.org/show_bug.cgi?id=736969 Waiting for 1.4 freeze period to be over before pushing for 1.4.3 and closing this bug.
Thanks a lot for the fix. I can confirm this does work fine now with master.
Hello, The following diff (which is in proposed fix) + percent = percent * 100 / queue->high_percent; + /* clip */ + if (percent > 100) + percent = 100; is not present in actual commit http://cgit.freedesktop.org/gstreamer/gstreamer/commit/?h=1.4&id=7630ada89a6360b7bc8304e5e08de43c36f1226f. What could be reason to omit this? The problem i am facing is that it queue2 never posting 100% buffering: $ gst-launch-1.0 souphttpsrc location=http://205.164.36.135:80 ! icydemux ! queue2 use-buffering=1 low-percent=10 high-percent=50 ! decodebin ! pulsesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Prerolled, waiting for buffering to finish... buffering... 50% With the above changes it works fine. i am testing with 1.4.3 release
commit 8d835ec400819140e5fc8532a90010c694e1212b Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Sun Nov 23 05:45:24 2014 -0300 queue2: percentage is relative to high-percent When comparing percentage values, compare with 0-100 scale as it has already been made relative to 0-high_percent, otherwise we mark the queue as not buffering and report a 50% to the user. This leads to a buffering stall as the user assumes the queue is still buffering but it thinks it isn't. https://bugzilla.gnome.org/show_bug.cgi?id=736969
1.4 branch: commit cafe1f2fc90acccd7aceb6d3c09bee6496396672 Author: Thiago Santos <thiagoss@osg.samsung.com> Date: Sun Nov 23 05:45:24 2014 -0300 queue2: percentage is relative to high-percent When comparing percentage values, compare with 0-100 scale as it has already been made relative to 0-high_percent, otherwise we mark the queue as not buffering and report a 50% to the user. This leads to a buffering stall as the user assumes the queue is still buffering but it thinks it isn't. https://bugzilla.gnome.org/show_bug.cgi?id=736969