Accessing unallocated memory when using nvv4l2decoder

I found a GStreamer-CRITICAL assertion error when running a GStreamer pipeline including the nvv4l2decoder plugin. Also an invalid read error was detected with Valgrind at the same time as the assertion occurred.

The pipeline I comfirmed is as below. I tested L4T 32.4.3 on TX2 when this issue reproduced.

$ gst-launch-1.0 filesrc location=/opt/nvidia/deepstream/deepstream/samples/streams/sample_1080p_h264.mp4 ! qtdemux ! h264parse ! nvv4l2decoder ! nvvideoconvert ! xvimagesink

“gst_mini_object_unref: assertion ‘GST_MINI_OBJECT_REFCOUNT_VALUE (mini_object) > 0’ failed” showed when the playback was interrupted by CTRL-C, but this issue seemed to be a time-sensitive problem and it occurred once in about ten times as long as I repeatedly tried that. When nvv4l2decoder was replaced with a soft decoder plugin, the assertion does not occur, so I think this issue is specific for nvv4l2decoder.

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 PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:00:11.009733310
Setting pipeline to PAUSED ...
Setting pipeline to READY ...

(gst-launch-1.0:4677): GStreamer-CRITICAL **: 19:32:23.470: gst_mini_object_unref: assertion 'GST_MINI_OBJECT_REFCOUNT_VALUE (mini_object) > 0' failed
Setting pipeline to NULL ...
Freeing pipeline ...

In GStreamer, this assertion means we attempt to decrement the reference count of a object that has been deleted due to the count having been dropped to 0.

That’s why Valgrind detected this occurrence as an invalid read error.
Here’s the test command line.

$ sudo apt install valgrind libgstreamer1.0-0-dbg
$ valgrind gst-launch-1.0 filesrc location=/opt/nvidia/deepstream/deepstream/samples/streams/sample_1080p_h264.mp4 ! qtdemux ! h264parse ! nvv4l2decoder ! nvvideoconvert ! xvimagesink

Then, the invalid read was observed as below.

Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
^Chandling interrupt.
Interrupt: Stopping pipeline ...
Execution ended after 0:00:03.525224057
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
==18054== Thread 1:
==18054== Invalid read of size 4
==18054==    at 0x48FE958: gst_mini_object_unref (gstminiobject.c:433)
==18054==    by 0x49F0213: g_value_unset (in /usr/lib/aarch64-linux-gnu/libgobject-2.0.so.0.5600.4)
==18054==  Address 0xc218778 is 8 bytes inside a block of size 72 free'd
==18054==    at 0x4845D58: free (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==18054==  Block was alloc'd at
==18054==    at 0x4844BFC: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==18054== 

(gst-launch-1.0:18054): GStreamer-CRITICAL **: 10:31:35.879: gst_mini_object_unref: assertion 'GST_MINI_OBJECT_REFCOUNT_VALUE (mini_object) > 0' failed
Setting pipeline to NULL ...
Freeing pipeline ...

Could you try to reproduce it and investigate what is the cause in the nvv4l2decoder plugin?

It will do no harm to the application since you terminated the application in abnormal way.

Hi,

gst-launch catches an interrupt signal and does the regular finalization processing in GStreamer, so this issue can occur in other general GStreamer application too.

Here’s the code.

After the finalization, we can also restart the pipeline with the GStreamer state change API, so there is a risk that this invalid read interrupts that operation to continue.