Deadlock in gst_element_set_state (not from streaming thread)

[Alexander Kordecki]

Hi,

I have a similar Problem with many udpsrc.
But I have the deadlock in „bus.timed_pop_filtered“ when waiting for EOS.

I have no good solution yet, I moved this part out of the mutex and now have around 1000 additional hanging threads each day.
So i'm doing regular restarts of this service. I hope it’s going to be fixed soon.

GStreamer 1.14.4

Best regards,
Alexander Kordecki

—
Dipl. Ing.					Beratung und Softwareentwicklung
Alexander Kordecki			für BigData, Datenbanken,
Veitstr. 34a 				Netzwerke und Telekommunikation
13507 Berlin				alex at kordecki.de
Germany					030 / 303 660 660

> Am 06.04.2021 um 13:18 schrieb Yukigaru <yukigaru at gmail.com>:
> 
> I have an application that processes network video steams and is dynamically
> adds/removes them. Scheme is following:
> 
> Left part (added many times): souphttpsrc ! parsebin ! rtph264pay !
> rtph264depay ! capsfilter ! h264parse ! queue ! nvv4l2decoder
> Right part (single instance): nvstreammux -> nvinfer -> nvinfer -> appsink
> 
> The dynamic part is created for each network stream and connects with its
> nvv4l2decoder to the static part.
> 
> The *issue* is that sometimes it *deadlocks* in
> gst_element_set_state(left_part_bin, NULL) upon removing the left part
> (because either the app got external signal to remove the stream or because
> of an error in the stream). The pseudo code of the removal is following:
> 
> void removeSource(...) {
>  deleteMutex.lock();
> 
>  gst_element_set_locked_state(left_part_bin, TRUE);
>  gst_element_set_state(left_part_bin, GST_STATE_NULL); <- deadlocks here
> 
>  auto src_pad = gst_element_get_static_pad(left_part_bin, "src");
>  gst_pad_unlink(src_pad, stream_muxer_sink_pad); // unlink from the right
> part
>  gst_bin_remove(pipeline, left_part_bin);
> 
>  deleteMutex.unlock();
> }
> 
> This removeSource is called from BusCallback function when the "nvstreammux"
> element receives the NVEOS message. I've thoroughly studied forums which say
> that you shouldn't do gst_element_set_state from streaming threads, but it
> seems that I don't do that anyway, because I think bus loop thread is not a
> streaming thread.
> 
> Are you familiar with that issue? Do I do something obviously wrong?
> 
> All errors from gst functions are carefully checked and logged.
> 
> Gstreamer: 1.14.5
> Plugins: Deepstream 5.0 for neural-network inference
> 
> 
> 
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel