GNOME Bugzilla – Bug 764725
splitmuxsink: deadlock on stream error
Last modified: 2018-11-03 15:08:54 UTC
splitmuxsink blocks streaming threads in handle_mq_input() but won't unblock them when there is a stream error. Since it won't receive any buffer after that, its blocked forever.
Created attachment 325539 [details] [review] splitmux: unblock on stream error
Hm, bus_handler() was not what I though. I don't know if an element can have access to pipeline bus?
What element generates the error here? Is it a child of splitmuxsink? Can you make a unit test? (e.g. with identity error-after=N)
Upstream is a RTSP src, stream error can happen on network errors for example.
In that case the pad block should be removed in the downward state change I guess?
Thinking a bit more about it, maybe it's a bug in my side actually. Splitmuxsink unblock streaming threads when receiving EOS on the reference pad, or when state change to READY or NULL. So I think the proper thing to do is sending eos on every pads when there is a StreamError coming from upstream. What my code is currently doing is first gst_element_release_request_pad() on splitmuxsink's pads before changing its state to NULL. But releasing the pad, takes the pad lock which is already held by the pad probe that blocks in handle_mq_input(). So that deadlock. I changed my code to first send EOS on each pad, then releasing request pads, then setting state to NULL, and it seems to work like that. So maybe this bug is INVALID, it's up to the user (me) to handle stream errors correctly?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/268.