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 736919 - hlsdemux: attempt to unlock an already unlocked mutex in gst_hls_demux_change_playlist
hlsdemux: attempt to unlock an already unlocked mutex in gst_hls_demux_change...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal normal
: 1.4.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-09-18 16:15 UTC by Philippe Normand
Modified: 2014-09-19 06:50 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
patch (1.18 KB, patch)
2014-09-18 16:22 UTC, Philippe Normand 		committed Details | Review

Description Philippe Normand 2014-09-18 16:15:33 UTC 
If we enter in the code below the retry_failover_protection label not triggered by a goto the demux->client mutex is unlocked and an attempt to unlock it is made after the current_variant update.
Comment 1 Philippe Normand 2014-09-18 16:16:22 UTC 
Happens with the now famous bipbop demo: https://devimages.apple.com.edgekey.net/streaming/examples/bipbop_4x3/bipbop_4x3_variant.m3u8
Comment 2 Philippe Normand 2014-09-18 16:22:46 UTC 
Created attachment 286518 [details] [review]
patch
Comment 3 Tim-Philipp Müller 2014-09-18 22:29:05 UTC 
Thanks, pushed:

commit 6d67b5263f505a8d23b2d4b92f05384baead4a22
Author: Philippe Normand <philn@igalia.com>
Date:   Thu Sep 18 18:16:59 2014 +0200

    hlsdemux: lock client mutex before entering the retry_failover block
    
    This is consistent with the case where the block execution is
    triggered by the goto invoked after the current_variant update.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=736919
Comment 4 Tim-Philipp Müller 2014-09-18 22:50:44 UTC 
The patch fixes the issue for me, but on second thought, shouldn't the lock be taken a bit earlier, before
  previous_variant = demux->client->main->current_variant;
?
Comment 5 Philippe Normand 2014-09-19 06:05:13 UTC 
Hum that would be better yes but then the lock needs to be released again just before the call to gst_m3u8_client_get_playlist_for_bitrate() to prevent a deadlock.
Comment 6 Sebastian Dröge (slomo) 2014-09-19 06:50:33 UTC 
While this is true, I backported it to 1.4 for 1.4.2 already as it fixes a real problem for now. That locking has to be reconsidered though :)