Kernel memory leak(s) with simple nvarguscamerasrc pipeline

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin NX
1

Hello,

I work with Jetpack-6.1 on an Orin NX based custom board.

With those simple pipelines

gst-launch-1.0 -v nvarguscamerasrc sensor-id=0 ! video/x-raw(memory:NVMM),width=2472,height=2064,framerate=15/1 ! nvjpegenc ! multifilesink location=/run/user/1000/livestream0/live.jpg max-files=5
gst-launch-1.0 -v nvarguscamerasrc sensor-id=1 ! video/x-raw(memory:NVMM),width=2472,height=2064,framerate=15/1 ! nvjpegenc ! multifilesink location=/run/user/1000/livestream1/live.jpg max-files=5

I had huge memory leaks.

After having configured the kernel with CONFIG_DEBUG_KMEMLEAK, I discovered the same bug as the one reported in Kernel memory leak per-frame with Argus cameras - r36.4

After having applied the fix proposed there, the huge memory leak has disappeared.

Nevertheless ‘sudo cat /sys/kernel/debug/kmemleak.’ reports another possible, but slower, memory leak

unreferenced object 0xffff0000dc2aa700 (size 128):
  comm "argus_thread", pid 1634, jiffies 4305698952 (age 30902.944s)
  hex dump (first 32 bytes):
    37 32 2d 61 72 67 75 73 5f 74 68 72 65 61 64 00  72-argus_thread.
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<0000000001750c20>] slab_post_alloc_hook+0x94/0x278
    [<00000000a9203836>] __kmalloc_track_caller+0x158/0x310
    [<0000000075b18ec2>] kvasprintf+0x94/0x128
    [<000000001aae5ca5>] kasprintf+0x64/0x88
    [<00000000b7fc469c>] host1x_syncpt_alloc+0x17c/0x1e0
    [<0000000029ea61d3>] tegra_drm_ioctl_syncpoint_allocate+0x58/0xf0
    [<00000000f3fa0ef9>] drm_ioctl_kernel+0xd8/0x128
    [<00000000b1063314>] drm_ioctl+0x2b8/0x620
    [<000000006a4b9421>] __arm64_sys_ioctl+0xb0/0xf0
    [<00000000c08d3c6c>] invoke_syscall+0x58/0x120
    [<000000007e7e5e5a>] el0_svc_common.constprop.3+0x8c/0x110
    [<00000000467a2901>] do_el0_svc+0x38/0x98
    [<0000000029f7bde1>] el0_svc+0x20/0x60
    [<00000000dc919b1c>] el0t_64_sync_handler+0x90/0xb8
    [<0000000096a1dbf2>] el0t_64_sync+0x184/0x188

Are you aware of this ?
Is this really a memory leak and is a fix available ?

Our application is expected to run 24/24 7/7, so even a small memory leak is a nuisance.

5

We are checking if able to repo the issue on reference sensor board first.

Thanks