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
write access, variable set to TRUE
gst_adaptive_demux_stop_tasks: no lock taken!
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