Deadlock in gst_element_set_state (not from streaming thread)

[Yukigaru]

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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[klex0]

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 [hidden email]
Germany 030 / 303 660 660

> Am 06.04.2021 um 13:18 schrieb Yukigaru <[hidden email]>:
>
> 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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel