GNOME Bugzilla – Bug 755232
dashdemux: demux->cancelled is not properly protected
Last modified: 2015-10-29 11:07:00 UTC
When a variable is shared between 2 threads, both read and write operations on the variable must be performed with the same lock taken. I've done an analysis on how demux->cancelled variable is locked before access: write access, variable set to FALSE gst_adaptive_demux_start_tasks: GST_MANIFEST_LOCK write access, variable set to TRUE gst_adaptive_demux_stop_tasks: no lock taken! read accesses: gst_adaptive_demux_stream_wait_manifest_update: GST_MANIFEST_LOCK gst_adaptive_demux_stream_download_uri: stream->fragment_download_lock gst_adaptive_demux_stream_download_header_fragment: no lock taken! gst_adaptive_demux_stream_download_loop: sometimes GST_OBJECT_LOCK (demux) + GST_MANIFEST_LOCK, sometimes GST_OBJECT_LOCK (demux), sometimes fragment_download_lock Seems that different readers use different locks and the writer (gst_adaptive_demux_stop_tasks) does not use any lock! What lock should be used for this variable? Or gst_adaptive_demux_stop_tasks function should grab all 3 locks when setting it?
Created attachment 311767 [details] [review] unlock mutexes in reverse locking order Found while looking at how the cancelled variable is used.
This is fixed as a side effect of Florian's patch from https://bugzilla.gnome.org/show_bug.cgi?id=755169