Multimedia API memory Leaks

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

I am working with the Tegra Multimedia API (Tegra_Multimedia_API_R24.2.2_aarch64) using
L4T R28:

# R28 (release), REVISION: 1.0, GCID: 9379712, BOARD: t186ref, EABI: aarch64, DATE: Thu Jul 20 07:59:31 UTC 2017

I wanted to check that my code was not leaking memory, so I built that latest version of valgrind from source on my TX2 system:

and ran it on the sample code in 01_video_encode.

Here is the summary:

==14832== HEAP SUMMARY:
==14832==     in use at exit: 86,855 bytes in 45 blocks
==14832==   total heap usage: 2,903 allocs, 2,858 frees, 7,925,054 bytes allocated

I am attaching the full valgrind log file for your reference as well as the commands I used to generate it.

Please advise on how to resolve these leaks in the Multimedia API.

valgrind.log (32.6 KB)

2

Here is the shell script contents to create the input raw movie file:

#!/usr/bin/env bash
../00_video_decode/video_decode ../../data/video/sample_outdoor_car_1080p_10fps.h264 H264 --disable-rendering -o decompressed.yuv

Here is the shell script contents to run valgrind on the video encoder:

#!/usr/bin/env bash
valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --log-file=valgrind.log -v ./video_encode decompressed.yuv 1920 1080 H264 ./out.h264 -fps 1 1

I added debug symbols to the compiler flags in the makefile:

CPPFLAGS += -std=c++11 -g -Wall
3

Sorry for late.
Can I reproduce this issue when running B01 video_encode without any modification?

4

@waynezhu

If you want to see the same result in valgrind you will need to update the makefile to include the CPPFLAGS I listed above. Then you can build example “01_video_encode”.

You will need a .yuv raw video file to use as an input for the app.

5

Hi ceres,
I got similar test result as yours.
But according to Valgrind, those “still reachable” are quite common and often reasonable.

nvidia@tegra-ubuntu:~/tegra_multimedia_api/samples/01_video_encode$ valgrind --leak-check=full --show-reachable=no --show-leak-kinds=all --track-origins=yes --log-file=valgrind.log1 -v ./video_encode decompressed.yuv 1920 1080 H264 ./out.h264 -fps 1 1
==10674== HEAP SUMMARY:
==10674== in use at exit: 85,457 bytes in 40 blocks
==10674== total heap usage: 2,910 allocs, 2,870 frees, 8,043,998 bytes allocated

==10674== LEAK SUMMARY:
==10674== definitely lost: 0 bytes in 0 blocks
==10674== indirectly lost: 0 bytes in 0 blocks
==10674== possibly lost: 0 bytes in 0 blocks
==10674== still reachable: 85,457 bytes in 40 blocks
==10674== suppressed: 0 bytes in 0 blocks

From Valgrind

5.2. With Memcheck’s memory leak detector, what’s the difference between “definitely lost”, “indirectly lost”, “possibly lost”, “still reachable”, and “suppressed”?
The details are in the Memcheck section of the user manual.
In short:
• “definitely lost” means your program is leaking memory – fix those leaks!
• “indirectly lost” means your program is leaking memory in a pointer-based structure. (E.g. if the root node of a binary tree is “definitely lost”, all the children will be “indirectly lost”.) If you fix the “definitely lost” leaks, the “indirectly lost” leaks should go away.
• “possibly lost” means your program is leaking memory, unless you’re doing unusual things with pointers that could cause them to point into the middle of an allocated block; see the user manual for some possible causes. Use --show-possibly-lost=no if you don’t want to see these reports.
• “still reachable” means your program is probably ok – it didn’t free some memory it could have. This is quite common and often reasonable. Don’t use --show-reachable=yes if you don’t want to see these reports.
• “suppressed” means that a leak error has been suppressed. There are some suppressions in the default suppression files. You can ignore suppressed errors.

6

Hi Ceres,
Do you mean this the memory leakage?
==10674== still reachable: 85,457 bytes in 40 blocks → I think THis is the memory from nvmap, not memory leakage.

Do you see obvious memory growth then run APP?