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/