[BUG]

Issue: nvstreammux SIGSEGV when reusing the same pipeline for a 2nd file after EOS (DS 9.1; works on DS 7.1)

Summary

We run a single DeepStream pipeline (filesrc → h265parse → nvv4l2decoder → nvstreammux → nvinfer → ... → encoder → filesink) and reuse it sequentially for multiple H.265 files: after a file reaches EOS we go GST_STATE_NULL → READY → PLAYING, change filesrc/filesink locations, and play the next file.

This works fine on DeepStream 7.1 (validated with 11 files / 3 resolution groups). On DeepStream 9.1 the same program segfaults at the 2nd file of the first group, inside the closed nvstreammux (libnvdsgst_multistream.so) while the decoder re-negotiates caps into the mux.

We believe nvstreammux cannot be safely reused after an EOS'd source in 9.1 (regression vs 7.1, or a behavior change). Since the nvstreammux source is now in this repo under src/gst-plugins/gst-nvmultistream2, we'd like to report it here.

---

Environment

Item	Crashes (DS 9.1 — dev box)	Works (DS 7.1 — prod box)
DeepStream image	nvcr.io/nvidia/deepstream:9.1-triton-multiarch	nvcr.io/nvidia/deepstream:7.1-triton-multiarch
DeepStream SDK	9.1	7.1
GPU	NVIDIA GeForce RTX 3060 (12 GB)	NVIDIA L20 (46 GB)
Driver	610.47.03 (KMD 610.60)	535.216.01
CUDA	UMD 13.3	12.6
Host	x86_64, Windows + WSL2 (Docker Desktop)	x86_64, Linux VM
GStreamer	as shipped inside the DS image	as shipped inside the DS image
Video codec	H.265 (NV12), 1920x1440 / 1920x1536 / 3840x2160	same files

⚠️ Confounding factors / what we have NOT been able to isolate: the two boxes differ not only in DeepStream version but also in GPU (consumer RTX 3060 vs datacenter L20), driver (610 vs 535), CUDA (13.3 vs 12.6) and host (WSL2 vs Linux VM). So the delta is not purely "DS 9.1 vs 7.1". We tried to run the 7.1 image on the dev box but could not: the DeepStream 7.1 container's CUDA runtime is incompatible with that box's newer driver/CUDA stack, and we don't want to downgrade the driver. So this is currently a field report: DS 9.1 + RTX 3060 + driver 610.47.03 / CUDA 13.3 + WSL2 → crashes; DS 7.1 + L20 + driver 535.216.01 / CUDA 12.6 → works.

If it would help isolate the variable, we can additionally run the 9.1-triton-multiarch image on an L20 (driver-535) box: if it crashes there too, that confirms DS 9.1 independent of the GPU/driver. Happy to try if you'd like that data point.

---

Behavior

• DS 7.1: all files processed, clean EOS, [FILE] Done. every time, no crash.
• DS 9.1: file #1 OK; at the start of file #2 (same pipeline, same resolution) → Segmentation fault.

Key log just before the crash (file #2 starting, model reloading):

=== [2/4] ===
[run] Input:  .../CAM5.h265
...
nvinfer ... deserialized trt engine from :...cadesen_26.8.1.engine
nvinfer ... Load new model:... sucessfully
Segmentation fault (core dumped)

---

Reproducer

Attached / reference: docs/deepstream_test/deepstream_test.cpp (single file, ~630 lines).

It:

1. reads a task file with lines input_file width height;
2. groups tasks by resolution;
3. builds one pipeline per group (nvstreammux configured to that resolution);
4. runs every file in the group through that same pipeline by cycling NULL → (change filesrc/filesink location) → READY → PLAYING, then waits for EOS.

The reuse step that triggers the bug is in process_single_file():

// next file: fully stop, then restart on the SAME pipeline
gst_element_set_state(g_state.pipeline, GST_STATE_NULL);
gst_element_get_state(g_state.pipeline, NULL, NULL, GST_CLOCK_TIME_NONE);
g_usleep(100000);

// drain bus
GstMessage* msg;
while ((msg = gst_bus_pop(g_state.bus)) != NULL)
    gst_message_unref(msg);

// point at the next input/output
g_object_set(G_OBJECT(g_state.filesrc), "location", task.input_file.c_str(), NULL);
g_object_set(G_OBJECT(g_state.sink),    "location", task.output_file.c_str(), NULL);

gst_element_set_state(g_state.pipeline, GST_STATE_READY);
gst_element_get_state(g_state.pipeline, NULL, NULL, GST_CLOCK_TIME_NONE);
gst_element_set_state(g_state.pipeline, GST_STATE_PLAYING);
g_main_loop_run(g_loop);   // runs until EOS

Pipeline topology (built once per group):

filesrc → h265parse → nvv4l2decoder ─┐
                                     ├─ nvstreammux (sink_0, batch-size=1)
nvinfer ← capsfilter(NV12 WxH) ←─────┘
nvvideoconvert → nvdsosd → nvvideoconvert
→ capsfilter(I420 WxH) → nvv4l2h265enc → filesink

Build

# DeepStream container, e.g.:
g++ -O2 -o deepstream_test deepstream_test.cpp \
    $(pkg-config --cflags --libs gstreamer-1.0 glib-2.0 gobject-2.0) \
    -I/opt/nvidia/deepstream/deepstream/sources/includes \
    -L/opt/nvidia/deepstream/deepstream/lib \
    -lnvdsgst_meta -lnvds_meta \
    -Wl,-rpath,/opt/nvidia/deepstream/deepstream/lib

Run

./deepstream_test \
  -t task.txt \
  -o /path/to/output_dir \
  -c /opt/nvidia/deepstream/deepstream/samples/configs/deepstream-app/config_infer_primary.txt   # any PGIE config

task.txt — two H.265 files of the SAME resolution are enough to trigger it:

/path/video_cam4.h265 1920 1440
/path/video_cam5.h265 1920 1440

Note: the crash appears to be independent of the model content — the fault fires while the decoder re-negotiates caps into the reused nvstreammux, right after the pipeline is restarted for file #2. We have not yet verified whether it reproduces with the inference stage removed entirely (e.g. decoder → nvstreammux → fakesink); let us know if that minimal variant would help.

---

Backtrace (gdb, DS 9.1)

Thread 16 "h265-parser:sin" received signal SIGSEGV, Segmentation fault.
0x00007f... in g_mutex_lock () from libglib-2.0.so.0

#0  g_mutex_lock ()                     libglib-2.0.so.0
#1  ??? ()                              libnvdsgst_multistream.so     <-- nvstreammux
#2  ??? ()                              libgstreamer-1.0.so.0
#3  ??? ()                              libgstreamer-1.0.so.0
#4  ??? ()                              libgstreamer-1.0.so.0
#5  ??? ()                              libgstreamer-1.0.so.0
#6  gst_pad_push_event ()               libgstreamer-1.0.so.0
#7  ??? ()                              libgstvideo-1.0.so.0
#8  gst_video_decoder_negotiate ()      libgstvideo-1.0.so.0
#9  ??? ()                              libgstnvvideo4linux2.so        <-- nvv4l2decoder
#10 ... (gst_video_decoder chain)
#16 gst_base_parse_push_frame ()        libgstbase-1.0.so.0
#17 ??? ()                              libgstvideoparsersbad.so       <-- h265parse

Decoder re-negotiation on the restart pushes an event into nvstreammux, which locks a mutex on (apparently) stale per-source state from the EOS'd source → SIGSEGV.

---

Expected vs actual

• Expected: after EOS, cycling NULL → READY → PLAYING and pointing filesrc at a new file on the same nvstreammux pipeline should start the new stream cleanly (as it does on DS 7.1).
• Actual: on DS 9.1 the 2nd file segfaults inside nvstreammux during caps negotiation.

---

Questions / possible cause

• Is reusing one nvstreammux pipeline across back-to-back EOS'd file streams supported in 9.1 at all? If not, what is the recommended way to process multiple files sequentially without rebuilding the mux?
• The crash looks like a per-source object/mutex is freed or reset on EOS but still referenced by the decoder during the next negotiation — i.e. a use-after-free/race between the state change and the streaming thread inside nvstreammux.

deepstream_test.cpp

deepstream_test.cpp

Start with docs/deepstream_test/deepstream_test.cpp, especially process_single_file(), and reproduce the crash using two same-resolution H.265 files on DeepStream 9.1. Run the proposed decoder → nvstreammux → fakesink variant to determine whether inference is involved, then compare the restart lifecycle and backtrace with the reported behavior. Done means isolating the failing component or establishing the supported reuse lifecycle.