Valgrind reports memory leakage on libnvrtc.so

Software versions:
CUDA: 10.2/11.4
TensorRT: 8.0.1.6/8.4.0.11
Valgrind: 3.19.0

Problem description
We use valgrind to test memory leaks on our programs, and valgrind reports 72704 bytes of memory leakage, the problem is caused by libnvrtc.so.

Here is a minimal example to reproduce the problem. This small example just dlopen the shared library and close it immediately.

#include <cstdio>
#include <dlfcn.h>

int main() {
    void* handle = dlopen("/usr/local/cuda/targets/aarch64-linux/lib/libnvrtc.so", RTLD_NOW);
    if (!handle) {
        fprintf(stderr, "load failed");
        return -2;
    }
    dlclose(handle);
}

and compile using

g++ main.cpp -o main -ldl

and run valgrind memory leak check

valgrind --tool=memcheck --leak-check=full --keep-debuginfo=yes -- ./main

The result is

...
==451089== 72,704 bytes in 1 blocks are definitely lost in loss record 6 of 6
==451089==    at 0x4849D8C: malloc (in /usr/lib/aarch64-linux-gnu/valgrind/vgpreload_memcheck-arm64-linux.so)
==451089==    by 0x4FCD33B: ??? (in /usr/local/cuda-11.4/targets/aarch64-linux/lib/libnvrtc.so.11.4.166)
==451089== 
==451089== LEAK SUMMARY:
==451089==    definitely lost: 72,704 bytes in 1 blocks
==451089==    indirectly lost: 0 bytes in 0 blocks
==451089==      possibly lost: 0 bytes in 0 blocks
==451089==    still reachable: 3,189 bytes in 10 blocks
==451089==         suppressed: 0 bytes in 0 blocks
==451089== Reachable blocks (those to which a pointer was found) are not shown.
==451089== To see them, rerun with: --leak-check=full --show-leak-kinds=all

Hi,

Thanks for reporting this.
Confirmed that we can reproduce this memory leakage issue in the JetPack5 environment.

We are going to check this with our internal team.
Will share more information with you later.

Thanks.

Hi,

We have checked this issue with our internal team.

The memory leak is in the c++ library runtime emergency pool:
The source code of eh_alloc.cc:
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/libsupc%2B%2B/eh_alloc.cc#L262

262 pool emergency_pool;

It is intentional the emergency_pool not be released.
So in the case at exit() time memory is exhausted, it can use emergency_pool.

Thanks.

How do you locate the issue? Is from backtrace?
We want to reproduce it.

Thanks

Hi,

Sorry that this is captured by running Valgrind with the nvrtc source.
But the library is not open-sourced.

Thanks.