[Bug 783627] gstvideodecoder.c: excessive locking triggering many deadlocks

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=783627

--- Comment #6 from minfrin at sharp.fm ---
Digging through this code, there are many deadlocks, not just the one.

A repeated pattern is code such as the following which locks the stream:

static void
gst_video_decoder_reset (GstVideoDecoder * decoder, gboolean full,
    gboolean flush_hard)
{
  GstVideoDecoderPrivate *priv = decoder->priv;

  GST_DEBUG_OBJECT (decoder, "reset full %d", full);

  GST_VIDEO_DECODER_STREAM_LOCK (decoder);

  ...
}

gst_video_decoder_reset() is then called in various places like this,
triggering an attempt to lock the stream twice:

static GstStateChangeReturn
gst_video_decoder_change_state (GstElement * element, GstStateChange
transition)
{
  ...

    case GST_STATE_CHANGE_READY_TO_PAUSED:
      GST_VIDEO_DECODER_STREAM_LOCK (decoder);
      gst_video_decoder_reset (decoder, TRUE, TRUE);
      GST_VIDEO_DECODER_STREAM_UNLOCK (decoder);

  ...

      GST_VIDEO_DECODER_STREAM_LOCK (decoder);
      gst_video_decoder_reset (decoder, TRUE, TRUE);
      GST_VIDEO_DECODER_STREAM_UNLOCK (decoder);

  ...
}

This is one example, there are many.

In a non-trivial pipeline (one that includes regegotiations) that processes
non-trivial data (live data, complete with discontinuities and dynamic
behaviour), we deadlock repeatedly.

This is caused by the gstvideodecoder.c code locking the stream, then calling
downstream functions of other elements, which make queries and send events back
upstream, which are in turn received by gstvideodecoder.c again, which then
tries to relock the already-locked stream - deadlock.

The same pattern exists in gstvideoencoder.c, and the same bugs.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.