Deadlock when deleting channels

• Hardware Platform (Jetson / GPU) both jetson and DGPU
• DeepStream Version 5.0.1
**• JetPack Version (valid for Jetson only)**latest
• TensorRT Version 7.0
• NVIDIA GPU Driver Version (valid for GPU only) 10.2
I refer to this link deepstream_reference_apps/runtime_source_add_delete at master · NVIDIA-AI-IOT/deepstream_reference_apps · GitHub to implement my own application. First, I delete all 8 rtsp sources , and immediately add 8 rtsp sources, after 5 second, delete all 8 rtsp sources, add 8 rtsp sources… However, after several hours, maybe 3 hours or 8 hours, the application stuck at gst_element_set_state() function which set source bin to NULL when deleting rtsp source.
Could you reproduce this issue?
And another question, when adding rtsp source, how can I know the source bin is inited? and when source bin is not inited completely, can I delete it immediately? I use uridecodebin.
Thanks.

The sample deepstream_reference_apps/runtime_source_add_delete at master · NVIDIA-AI-IOT/deepstream_reference_apps · GitHub has been tested before it being published. Do you mean you met deadlock with this sample after running for 3-8 hours?

@Fiona.Chen,thanks for your reply.
I don’t run this sample 3-8 hours, I refer to this sample to implement my own application. The sample only add 1 channel 10s until list is full, then delete 1 channel 10s one by one. But in my application, I add all 8 channels at the same time, after 5s, delete all 8 channels and add all 8 channels, then after 5s , delete all 8 channels and add all 8 channels again…About 3-8 hours laters, the application stuck at gst_element_set_state() function which in the following code.

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) {
case GST_STATE_CHANGE_SUCCESS:
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]);
source_id–;
g_num_sources–;
break;
case GST_STATE_CHANGE_FAILURE:
g_print (“STATE CHANGE FAILURE\n\n”);
break;
case GST_STATE_CHANGE_ASYNC:
g_print (“STATE CHANGE ASYNC\n\n”);
state_return =
gst_element_get_state (g_source_bin_list[source_id], NULL, NULL,
GST_CLOCK_TIME_NONE);
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 ASYNC %p\n\n”, sinkpad);
gst_object_unref (sinkpad);
gst_bin_remove (GST_BIN (pipeline), g_source_bin_list[source_id]);
source_id–;
g_num_sources–;
break;
case GST_STATE_CHANGE_NO_PREROLL:
g_print (“STATE CHANGE NO PREROLL\n\n”);
break;
default:
break;
}
}

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.
Thanks

Can you modify runtime_source_add_delete to reproduce the problem you reported?