GNOME Bugzilla – Bug 783777
Deadlock gstpad vs decodebin2
Last modified: 2018-05-07 15:56:01 UTC
Created attachment 353730 [details] Deadlock callstacks During dash playback there is an error between pad posting an event (which goes to decoebin2 on its pad) and decodebin2 trying to modify pad state. From the dump (attached): Thread 21:
+ Trace 237575
/* lock order: STREAM_LOCK, LOCK, recheck flushing. */ GST_OBJECT_UNLOCK (pad); GST_PAD_STREAM_LOCK (pad); <===== Lock taken here, as EOS event is serialized need_unlock = TRUE; GST_OBJECT_LOCK (pad); if (G_UNLIKELY (GST_PAD_IS_FLUSHING (pad))) goto flushing; if (G_UNLIKELY (GST_PAD_IS_EOS (pad))) goto eos; } break; } /* now do the probe */ PROBE_PUSH (pad, type | GST_PAD_PROBE_TYPE_PUSH | GST_PAD_PROBE_TYPE_BLOCK, event, probe_stopped); PROBE_PUSH (pad, type | GST_PAD_PROBE_TYPE_PUSH, event, probe_stopped); eventfullfunc = GST_PAD_EVENTFULLFUNC (pad); eventfunc = GST_PAD_EVENTFUNC (pad); if (G_UNLIKELY (eventfunc == NULL && eventfullfunc == NULL)) goto no_function; ACQUIRE_PARENT (pad, parent, no_parent); GST_OBJECT_UNLOCK (pad); ret = pre_eventfunc_check (pad, event); <= executes this (gdb) print *event $5 = {mini_object = {type = 3052471832, refcount = 54, lockstate = 0, flags = 0, copy = 0xb69c6751 <_gst_event_copy>, dispose = 0x0, free = 0xb69c68bd <_gst_event_free>, n_qdata = 0, qdata = 0x0}, type = GST_EVENT_EOS, timestamp = 18446744073709551615, seqnum = 8629}
Does this still happen with 1.12, and also with the other decodes than the brcm ones?
(In reply to Sebastian Dröge (slomo) from comment #1) > Does this still happen with 1.12, and also with the other decodes than the > brcm ones? It is repeatable on 1.8.3 on RDK based set-top-box device. It may be difficult to try this quickly on the target device using 1.12.x as it may require some porting work (patches etc.). Also that makes the decoder switching difficult. The problems seems to be related to dash playback with stream switching during playback (mainly audio; note: track switching - not bitrate for adaptive playback). In that case the "old" pads are sending EOS messages. It looks that there is a problem related to handling these events. I would try to reproduce this on Linux with both version but do not know when I would be able to do this; I would add a comment here when ready.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!