[Bug 766064] basesink: deadlock waiting prerolling while pipeline goes to NULL state

[GStreamer (GNOME Bugzilla)]

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

--- Comment #14 from Miguel París Díaz <mparisdiaz at gmail.com> ---
(In reply to Sebastian Dröge (slomo) from comment #13)
> Your problem is that you don't set the pipeline to NULL state, but some
> element that is upstream of a sink while its streaming thread is busy inside
> the sink. This can't work and will block the state change until something is
> shutting down the sink (or flushing it).
No, in the real case I am setting the entire pipeline to NULL (the test is an
example that forces the situation in an easy way, in the GDB output attached
you can see that the deadlock is the same in both cases).

> If you set the pipeline to NULL state it should work just fine, as the state
> changes are happening from sink to source.
> 
Here is the problem, when all elements of the pipeline are set to PAUSE state.
Take a look to this race condition:
  1 - [app_thread] when the pipeline is going to NULL the BaseSink (in our case
a FakeSink) is set to READY, so it needs to do prerolling.
  2 - [streaming_thread] A buffer arrives to the BaseSink
    2.1 - This causes preroll_wait [1].
    2.2 - Here, the streaming_thread is blocked and so all upstream pads
  3- [app_thread] tries to change the state to PAUSE of the bin that contains
the as deadlocked ProsyPad (in 2.2)
    3.1 - it is blocked in [3] because the mutex is locked by
[streaming_thread]

Reviewing the GDB traces I have noticed that the transition to be set is
PAUSED_TO_READY [1].
This should've been PLAYING_TO_PAUSE, shouldn't it?
Can the problem be here?

Refs
[1]
#14 0x00002b0fd37d9f3d in gst_element_change_state
(element=element at entry=0xbf3bb0 [GstDtlsSrtpDec],
transition=transition at entry=GST_STATE_CHANGE_PAUSED_TO_READY) at
gstelement.c:2648
#15 0x00002b0fd37da74c in gst_element_set_state_func (element=0xbf3bb0
[GstDtlsSrtpDec], state=GST_STATE_READY) at gstelement.c:2602

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