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 781320 - adaptivedemux: Don't hold locks when pushing FLUSH_START
adaptivedemux: Don't hold locks when pushing FLUSH_START
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
unspecified
Other All
: Normal normal
: 1.11.91
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-04-14 16:18 UTC by Edward Hervey
Modified: 2017-04-15 06:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
adaptivedemux: Don't hold locks when pushing FLUSH_START (1.16 KB, patch)
2017-04-14 16:18 UTC, Edward Hervey
none Details | Review
adaptivedemux: Don't hold locks when pushing FLUSH_START (1.46 KB, patch)
2017-04-14 16:36 UTC, Edward Hervey
committed Details | Review

Description Edward Hervey 2017-04-14 16:18:09 UTC
See commit
Comment 1 Edward Hervey 2017-04-14 16:18:13 UTC
Created attachment 349871 [details] [review]
adaptivedemux: Don't hold locks when pushing FLUSH_START

Some actions (Qos, reconfigure, ...) might take place before we finish pushing out flush_start.
Comment 2 Edward Hervey 2017-04-14 16:31:49 UTC
The problem is that:
1) The QOS handling in adaptivedemux takes the MANIFEST LOCK
  That QOS event comes from basesink with its PREROLL_LOCK taken
2) FLUSH_START is sent from adaptivedemux with the MANIFEST_LOCK taken and the basesink flushing handler needs to take the PREROLL_LOCK

 => deadlock
Comment 3 Edward Hervey 2017-04-14 16:36:09 UTC
Created attachment 349873 [details] [review]
adaptivedemux: Don't hold locks when pushing FLUSH_START

Some actions (Qos, reconfigure, ...) might take place before we finish pushing out flush_start.

One problem would be that:
1) The QOS handling in adaptivedemux takes the MANIFEST LOCK
  That QOS event comes from basesink with its PREROLL_LOCK taken
2) FLUSH_START is sent from adaptivedemux with the MANIFEST_LOCK taken and the basesink flushing handler needs to take the PREROLL_LOCK

 => deadlock
Comment 4 Edward Hervey 2017-04-15 06:19:11 UTC
commit e00be2758528eb4ddb326efe4c261ce3b776a6e5
Author: Edward Hervey <edward@centricular.com>
Date:   Fri Apr 14 18:16:28 2017 +0200

    adaptivedemux: Don't hold locks when pushing FLUSH_START
    
    Some actions (Qos, reconfigure, ...) might take place before we finish pushing out flush_start.
    
    One problem would be that:
    1) The QOS handling in adaptivedemux takes the MANIFEST LOCK
      That QOS event comes from basesink with its PREROLL_LOCK taken
    2) FLUSH_START is sent from adaptivedemux with the MANIFEST_LOCK taken and the basesink flushing handler needs to take the PREROLL_LOCK
    
     => deadlock
    
    https://bugzilla.gnome.org/show_bug.cgi?id=781320