[Bug 752213] tee: Avoid race condition while forwarding sticky events

[GStreamer (GNOME Bugzilla)]

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

--- Comment #57 from Miguel París Díaz <mparisdiaz at gmail.com> ---
Created attachment 373443
  --> https://bugzilla.gnome.org/attachment.cgi?id=373443&action=edit
Simple program to force deadlock

Hi folks!!

A rare but real use case has been found that shows that attachment 369659
provokes a deadlock.
I have invested some efforts to understand it and I achieved the simple program
attached that reproduces the deadlock:

There are 3 threads:
 - app_thread: performs the initial pipeline creation and waits until the
expected actions are done
 - src_streaming_thread: managed by the task of the SrcPad of a FakeSrc
 - queue_streaming_thread: managed by the task of the SrcPad of a Queue

Requirements to force the deadlock:
-  Make the fakesrc to push 2 buffers and the EOS
 - Make the queue to be filled with 1 buffer

The race condition that provokes the deadlock is:
  1 - [app_thread] tee0, queue0 and fakesink0 are linked
    1.1 - waits until the buffer from (5.3) is pushed.
  2 - [src_streaming_thread] push the first buffer
    2.1 - it is forwarded to tee0:src_0 and queue0:sink
  3 - [queue_streaming_thread] push the first buffer
    3.1 - it is blocked at buffers_probe WAITING to link tee and fakesink1
  4 - [src_streaming_thread] push the second buffer
    4.1 - it is forwarded to tee0:src_0 and queue0:sink
    4.2 - as queue_streaming_thread is blocked, the queue is filled
  5 - [src_streaming_thread] push the EOS
    5.1 - tee: hold GST_TEE_EVENTS_LOCK and push EOS to tee:src_0
    5.2 - SIGNAL queue_streaming_thread to link tee and fakesink1
    5.3 - push a new buffer downstream
    5.4 - LOCKED because the queue is OVERRUN
  6 - [queue_streaming_thread] perform tee and fakesink1 linking
    6.1 - LOCKED at gst_tee_request_new_pad because GST_TEE_EVENTS_LOCK is hold
by the src_streaming_thread

The deadlock happens due to (5.4) and (6.1)

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