Releasing nvstreammux request pad results in a deadlock

• Hardware Platform (Jetson / GPU)
• DeepStream Version
• JetPack Version (valid for Jetson only)
• TensorRT Version

• Issue Type( questions, new requirements, bugs)
Questions, possible bug

• How to reproduce the issue ? (This is for bugs. Including which sample app is using, the configuration files content, the command line used and other details for reproducing)

This issue seems to be identical to Deadlock in gst_element_release_request_pad with nvstreammux, which has been fixed, according to the Issue.

I’m running into the same problem with dynamic source removal, using the code from the

The difference In my application is that I’m using RTSP sources, instead of URI sources.

First, the solution works properly as long as the first source added successfully connects. I can then add and remove additional sources without any problems.

However, if the first source fails to connect due to a socket timeout, unlinking the source and releasing the requested sink pad will result in deadlock.

I’m able to use the following code snippet, from your example in my application

static void
stop_release_source (gint source_id)
  GstStateChangeReturn state_return;
  gchar pad_name[16];
  GstPad *sinkpad = NULL;
  state_return =
      gst_element_set_state (g_source_bin_list[source_id], GST_STATE_NULL);
  switch (state_return) {
      g_print ("STATE CHANGE SUCCESS\n\n");
      g_snprintf (pad_name, 15, "sink_%u", source_id);
      sinkpad = gst_element_get_static_pad (streammux, pad_name);
      gst_pad_send_event (sinkpad, gst_event_new_flush_stop (FALSE));
      gst_element_release_request_pad (streammux, sinkpad);
      g_print ("STATE CHANGE SUCCESS %p\n\n", sinkpad);
      gst_object_unref (sinkpad);
      gst_bin_remove (GST_BIN (pipeline), g_source_bin_list[source_id]);

with deadlock occurring at

gst_element_release_request_pad (streammux, sinkpad);

Is something additional required to make the above work on a failed connection?


Hey, does the issue persist when you try local input files?

@bcao, I’ve been unable to reproduce the issue using local files, as I’m unable to get a URI source to fail in the same way.

With the RTSP failure, I can see that the stream selection callback gets called… with the socket timeout occurring shortly after.

Trying to release the pad after socket timeout is when the deadlock occurs.

Ok, just to confirm, so you don’t modify any code of and just replace the sources as RTSP, right?

@bcao give me a day and I will try and get you a simple repo script based on the example

There is no update from you for a period, assuming this is not an issue any more.
Hence we are closing this topic. If need further support, please open a new one.

Hi rjhowell44,

Any update? Is this still an issue to support?