Pipeline Crash

[bitren]

Please provide complete information as applicable to your setup.

• Hardware Platform (Jetson)
• DeepStream Version (8.0)
• JetPack Version (7.0)
• TensorRT Version
• Issue Type( bugs)
• 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)

My gstreamer pipeline is appsrc→nvvideoconvert→nvv4l2h264enc→appsink
My pipeline xdot file

0.00.00.037606381-surround0-pipeline.zip (2.0 KB)
My program sometimes crashes，and backtrace as follow
#0 0x0000fffd1c5f3a24 in ??? () at /usr/lib/aarch64-linux-gnu/tegra-egl/libEGL_nvidia.so.0
#1 0x0000fffd1c5f3d54 in ??? () at /usr/lib/aarch64-linux-gnu/tegra-egl/libEGL_nvidia.so.0
#2 0x0000fffd1c5f3010 in ??? () at /usr/lib/aarch64-linux-gnu/tegra-egl/libEGL_nvidia.so.0
#3 0x0000fffd1c5f0910 in ??? () at /usr/lib/aarch64-linux-gnu/tegra-egl/libEGL_nvidia.so.0
#4 0x0000fffd1c59f18c in ??? () at /usr/lib/aarch64-linux-gnu/tegra-egl/libEGL_nvidia.so.0
#5 0x0000ffff6f9df738 in ??? () at /usr/lib/aarch64-linux-gnu/nvidia/libnvbufsurftransform.so.1.0.0
#6 0x0000ffff6f9e21e8 [PAC] in NvBufSurfTransformAsync () at /usr/lib/aarch64-linux-gnu/nvidia/libnvbufsurftransform.so.1.0.0
#7 0x0000ffff71616cd0 [PAC] in ??? () at /usr/lib/aarch64-linux-gnu/gstreamer-1.0/deepstream/libgstnvvideoconvert.so
#8 0x0000ffffab0aefb8 [PAC] in ??? () at /lib/aarch64-linux-gnu/libgstbase-1.0.so.0
#9 0x0000ffffab0ae3dc [PAC] in ??? () at /lib/aarch64-linux-gnu/libgstbase-1.0.so.0
#10 0x0000ffffb02dcb68 [PAC] in ??? () at /lib/aarch64-linux-gnu/libgstreamer-1.0.so.0
#11 0x0000ffffb02dfcfc [PAC] in ??? () at /lib/aarch64-linux-gnu/libgstreamer-1.0.so.0
#12 0x0000ffffb02e02b0 [PAC] in gst_pad_push () at /lib/aarch64-linux-gnu/libgstreamer-1.0.so.0
#13 0x0000ffffab0b22ec [PAC] in ??? () at /lib/aarch64-linux-gnu/libgstbase-1.0.so.0
#14 0x0000ffffb030df60 [PAC] in ??? () at /lib/aarch64-linux-gnu/libgstreamer-1.0.so.0
#15 0x0000ffffb00c7940 [PAC] in ??? () at /lib/aarch64-linux-gnu/libglib-2.0.so.0
#16 0x0000ffffb00c1388 [PAC] in ??? () at /lib/aarch64-linux-gnu/libglib-2.0.so.0
#17 0x0000ffffb31c595c [PAC] in start_thread (arg=0xffff64fbe780) at ./nptl/pthread_create.c:447
#18 0x0000ffffb322bb0c in thread_start () at
**

How should I further analyze the problem and resolve this crash？**

[fanzh]

1. What is the Jetson device model? Please refer to the compatibility table. DS8.0 only supports Thor.
2. Noticing the source format is UYVY, can the following cmd work well?
   gst-launch-1.0 -v videotestsrc ! video/x-raw,format=UYVY,width=2592,height=1944,framerate=25/1 ! nvvideoconvert ! video/x-raw\(memory:NVMM\),format=NV12 ! nvv4l2h264enc ! fakesink
   if crash, could you share the complete running log? and use gdb to get a complete crash stack trace? Thanks!

[bitren]

1.My Thor is 120W mode.

2.gst-launch-1.0 -v videotestsrc ! video/x-raw,format=UYVY,width=2592,height=1944,framerate=30/1 ! nvvideoconvert ! nvv4l2h264enc ! fakesink works well.

And my program crashes somewhat randomly.Sometimes it runs normally for 12 hours. Sometimes it crashes after a quarter of the run.

[fanzh]

1. When the issue happens, could you share the complete running log? wondering if there is any abnormal information, and please share the system log generated with “sudo nvidia-bug-report-tegra.sh”. Thanks!
2. How long did you run the cmd in your comment? what did you do in appsrc and appsink? To rule out the custom code’s issue, you can run the cmd for a long time to check if the issue persists.

[bitren]

@fanzh

When the issue happens, could you share the complete running log? wondering if there is any abnormal information, and please share the system log generated with “sudo nvidia-bug-report-tegra.sh”. Thanks!

Due to interference from other issues, I have not yet reproduced the problem。
And I cant find the script “nvidia-bug-report-tegra.sh“ on my Thor.How can i get it.

@fanzh

How long did you run the cmd in you my comment? what did you do in appsrc and appsink, to rule out the custom code’s issue, you can run the cmd for a long time to check if the issue persists.

I tested your cmd for 24 hours and it ran normally without any problems.
In my appsrc i push the data to gst-pipe as follow

GstMapInfo map;
GstBuffer *buffer = gst_buffer_new_allocate(NULL, size, NULL);
if (gst_buffer_map(buffer, &map, GST_MAP_WRITE)) {
  memcpy(map.data, data, size);
  gst_buffer_unmap(buffer, &map);
  GstClockTime gst_timestamp = _context.frame_cnt * GST_SECOND / 30;
  GstClockTime duration = GST_SECOND / 30;
  GST_BUFFER_PTS(buffer) = gst_timestamp;
  _context.frame_cnt++;
  GST_BUFFER_DURATION(buffer) = duration;
  GstFlowReturn flow_ret;
  g_signal_emit_by_name(_context.gst_elements.image_src, "push-buffer", buffer, &flow_ret);
}
gst_buffer_unref(buffer);

And in my appsink, i read the data out as follow.

GstSample *sample = NULL;
GstBuffer *buffer = NULL;
GstMapInfo map;
g_signal_emit_by_name(sink, "pull-sample", &sample);
if (sample) {
    buffer = gst_sample_get_buffer(sample);
    if (buffer && gst_buffer_map(buffer, &map, GST_MAP_READ)) {
      memcpy(dest, data, size);
      gst_buffer_unmap(buffer, &map);
    }
    gst_sample_unref(sample);
}
return GST_FLOW_OK;

Another issue：
My program starts automatically upon startup。
During the program startup process, a warning message is prompted。
WARNING: All NvMap Allocations must have a tag to identify the subsystem allocating memory.Please pass the tag to the API call NvRmMemHanldeAllocAttr() or relevant.
How to handle the warning?
An old topic saying can be ignored as follow, should I still Ignore It ?

How to handle the warning.Please pass the tag to the API call NvRmMemHanldeAllocAttr() or relevant

The pipeline will get the warning on TX2 nvidia@tegra-tx2:~$ gst-launch-1.0 filesrc location=1.h264 ! h264parse ! nvv4l2decoder bufapi-version=true ! nvvideoconvert name=vidconv ! 'video/x-raw(memory:NVMM),format=(string)RGBA,width=1024,height=540' ! fakesink Setting pipeline to PAUSED ... Opening in BLOCKING MODE Pipeline is PREROLLING ... NvMMLiteOpen : Block : BlockType = 261 NVMEDIA: Reading vendor.tegra.display-size : status: 6 NvMMLiteBlockCreate : Block : BlockType = 261 Pipeline is PRE…

[fanzh]

1. from the doc, the path is usr/bin/nvidia-bug-report-tegra.sh, or you can find it with “find” cmd. Or you can sudo dmesg > kernel.log to get kernel log.
2. from the pipeline you shared, the nvbuf-memory-type of nvvideoconvert is set to nvbuf-mem-surface-array. On Thor, the default value is nvbuf-mem-cuda-device. why do need to change this value?
3. noting “I tested your cmd for 24 hours and it ran normally without any problems.”, you can compare the pipeline with yours? you can use “appsrc->…->fakesink” and “videotestsrc->…->appsink” to narrow down the issue.
4. please refer to this topic for how to start app when reboot. regarding “All NvMap Allocations must have…”, that would outside of Deepstream. As the Jetson team said, you can ignore it.

[bitren]

@fanzh

2.from the pipeline you shared, the nvbuf-memory-type of nvvideoconvert is set to nvbuf-mem-surface-array. On Thor, the default value is nvbuf-mem-cuda-device. why do need to change this value?

run gst-inspect-1.0 nvvideoconvert ，i got

nvbuf-memory-type : Type of NvBufSurface Memory to be allocated for output buffers
flags: readable, writable, changeable only in NULL or READY state
Enum “GstNvBufMemoryType” Default: 2, “nvbuf-mem-cuda-device”
(0): nvbuf-mem-default - Default memory allocated, specific to particular platform
(1): nvbuf-mem-cuda-pinned - Allocate Pinned/Host cuda memory
(2): nvbuf-mem-cuda-device - Allocate Device cuda memory
(3): nvbuf-mem-cuda-unified - Allocate Unified cuda memory
(4): nvbuf-mem-surface-array - Allocate Surface Array memory, applicable for Jetson

I thought this setting would be better for Jetson**.Is there any risk associated with it?**

[fanzh]

Default: 2, “nvbuf-mem-cuda-device”. nvbuf-mem-surface-array is only supported in Jetson. not would be better for Jetson. Is there any new findings in your issue? as written in my last comment.

[bitren]

I have reproduced the crash. The GST_DEBUG was set 5.
Log as follows，and I did not find any obvious identifiable points in the logs。

202512_17.log.zip (9.8 KB)
I am currently preparing to experiment with your suggestions.

[fanzh]

There is not enough information in the log 202512_17.log.zip. Is there any update in your new test? Please refer to DeepStream native appsrc sample deepstream-appsrc-test. Please check if “gst_buffer_unref(buffer);” is needed.