Ubuntu – Determining if a memory leak is a false positive

The short of it: The situation you have described above is NOT a memory leak, in the sense that a piece of memory was allocated (eg: via malloc) assigned to a pointer, and later on the pointer was over-written or otherwise lost (scope), resulting in an explicit free of the allocated memory not being carried out.

So what is this leak report that valgrind is giving?

The Standard library implementations have a lot of leeway in regards to how they implement specified C++ standard features.

In your case, what you are seeing is that libc++, unlike libstdc++, creates a Thread Local Storage (TLS) instance of memory (via __calloc_with_fallback ) the first time the executable (aka process) attempts to throw an exception within a given thread (main is also considered as being a thread).

__cxa_eh_globals * __cxa_get_globals () {
//  Try to get the globals for this thread
    __cxa_eh_globals* retVal = __cxa_get_globals_fast ();

//  If this is the first time we've been asked for these globals, create them
    if ( NULL == retVal ) {
        retVal = static_cast<__cxa_eh_globals*>
                    (__calloc_with_fallback (1, sizeof (__cxa_eh_globals)));
        if ( NULL == retVal )
            abort_message("cannot allocate __cxa_eh_globals");
        if ( 0 != std::__libcpp_tls_set ( key_, retVal ) )
           abort_message("std::__libcpp_tls_set failure in __cxa_get_globals()");
       }
    return retVal;
    }

The code can be found here:

https://github.com/llvm/llvm-project/blob/main/libcxxabi/src/cxa_exception_storage.cpp#L80

The libc++ code that instantiates the memory immediately registers the associated pointer with a shutdown memory manager via the call to __libcpp_tls_set.

The idea here is that as part of the process shutdown procedure: Once all the state of the process has been free/destroyed/cleaned-up the TLS associated allocations (as there could be more than one thread in the process) registered with __libcpp_tls_set are then finally released (or freed).

Valgrind raises an issue here as it’s not able to track the the true location of allocation and line it up with its associated destruction, though all the memory allocated since the start of the process running is eventually freed explicity – and not implicitly via OS clean-up.

The leak you are seeing can easily be replicated with the following code:

int main()
{
    try
    {
        throw 1;
    }
    catch (int)
    {} 

    return 0;
}

Build:

c++ -pedantic-errors -Wall -Wextra -Werror -O2 -o exceptiontest exceptiontest.cpp -L/usr/lib -lc++

Run valgrind:

valgrind –leak-check=full –show-reachable=yes –track-origins=yes –log-file=exceptiontest.log -v ./exceptiontest

Valgrind output:

==551373== HEAP SUMMARY:
==551373==     in use at exit: 16 bytes in 1 blocks
==551373==   total heap usage: 2 allocs, 1 frees, 160 bytes allocated
==551373==
==551373== Searching for pointers to 1 not-freed blocks
==551373== Checked 135,200 bytes
==551373==
==551373== 16 bytes in 1 blocks are still reachable in loss record 1 of 1
==551373==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==551373==    by 0x48AE65F: ??? (in /usr/lib/llvm-14/lib/libc++abi.so.1.0)
==551373==    by 0x48AD4E9: __cxa_get_globals (in /usr/lib/llvm-14/lib/libc++abi.so.1.0)
==551373==    by 0x48B03F6: __cxa_throw (in /usr/lib/llvm-14/lib/libc++abi.so.1.0)
==551373==    by 0x109105: main (in temp/exception_test/exceptiontest)
==551373==
==551373== LEAK SUMMARY:
==551373==    definitely lost: 0 bytes in 0 blocks
==551373==    indirectly lost: 0 bytes in 0 blocks
==551373==      possibly lost: 0 bytes in 0 blocks
==551373==    still reachable: 16 bytes in 1 blocks
==551373==         suppressed: 0 bytes in 0 blocks
==551373==
==551373== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

As you can see the written program is very simple and completely standards conforming and does not either explicitly or implicitly leak memory, but yet depending on the c++ standard library implementation used, valgrind will raise an issue related to non-freed blocks.

When building the program with libstdc++, as expected no leaks or reachable blocks are generated:

==551500== HEAP SUMMARY:
==551500==     in use at exit: 0 bytes in 0 blocks
==551500==   total heap usage: 2 allocs, 2 frees, 73,860 bytes allocated
==551500==
==551500== All heap blocks were freed -- no leaks are possible
==551500==
==551500== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)