Valgrind displays memory leak in the unittest-cpp library

Question

I'm using unittest-cpp library. And I decided to check for memory leaks one of the units with valgrind help. I got such report:

==35820== HEAP SUMMARY:
==35820== in use at exit: 26,151 bytes in 188 blocks
==35820== total heap usage: 259 allocs, 71 frees, 32,151 bytes allocated
==35820==
==35820== 148 (80 direct, 68 indirect) bytes in 1 blocks are definitely lost in loss record 43 of 65
==35820== at 0x100023D81: malloc (vg_replace_malloc.c:303)
==35820== by 0x1002CB8D6: __Balloc_D2A (in /usr/lib/system/libsystem_c.dylib)
==35820== by 0x1002CC21F: __d2b_D2A (in /usr/lib/system/libsystem_c.dylib)
==35820== by 0x1002C8877: __dtoa (in /usr/lib/system/libsystem_c.dylib)
==35820== by 0x1002F13E6: __vfprintf (in /usr/lib/system/libsystem_c.dylib)
==35820== by 0x10031A6C8: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==35820== by 0x1002F0389: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==35820== by 0x1002EE223: printf (in /usr/lib/system/libsystem_c.dylib)
==35820== by 0x10000AA59: UnitTest::TestReporterStdout::ReportSummary(int, int, int, float) (TestReporterStdout.cpp:43)
==35820== by 0x10000AF9E: UnitTest::TestRunner::Finish() const (TestRunner.cpp:43)
==35820== by 0x10000B2F4: int UnitTest::TestRunner::RunTestsIf(UnitTest::TestList const&, char const*, UnitTest::True const&, int) const (in ./BuilderTests)
==35820== by 0x10000ACEF: UnitTest::RunAllTests() (TestRunner.cpp:17) ==35820==
==35820== LEAK SUMMARY:
==35820== definitely lost: 80 bytes in 1 blocks
==35820== indirectly lost: 68 bytes in 2 blocks
==35820== possibly lost: 2,064 bytes in 1 blocks
==35820== still reachable: 4,096 bytes in 1 blocks
==35820== suppressed: 19,843 bytes in 183 blocks

But valgrind didn't point to my code. Then I decided to build and check units from the GSL library, which uses unittest-cpp too. And I got the same report.

Can I trust valgrind?

Answer 1

You can usually trust Valgrind in that the memory is allocated there and not freed. Whether it is a problem or not, is another question.

This actually seems to be buffer allocated for stdout/stderr for performance reasons, which is indeed not freed by the C library on purpose.

You can try calling:

setbuf(stdout, NULL);
setbuf(stderr, NULL);

as the very first thing of the program and see if the Valgrind errors will go away. However it isn't a good thing to do, because the buffers are there for better performance. So it might be better to ignore this error (i.e. add it to the Valgrind suppression file).

(as you are using an unit-test framework, it might be actually kind of difficult to do this as the very first thing, because the framework will probably step in the way - one possibility might be to create a static global instance of an object which will call these in its constructor)

Answer 2

You can usually trust Valgrind to report facts. But how you interpret those is important. Not all leaks are equal.

Not all memory leaks are a problem. A program may legitimately neglect to free some objects during shutdown if their destructors are known to not have relevant work to do and thus "leak" them - leaving it up to the operating system to clear up the memory when the process exits.

So, there may be a real issue, sure. But it may also be that the library is intentionally leaking some objects for performance or convenience reasons.

A memory leak is only really a problem if it causes memory use to continuously increase during runtime.

A leak as in - a resource is allocated once and persists until the end of the program and is never freed - is only really a problem if that resource is of a significant size and could be released early so the memory could be used for something better, and/or if the resource has a destructor that it is important to run.

Remember that once the program terminates, all memory it allocated is returned to the system (rare exceptions like "sysv shared memory" and such excepted). A memory leak cannot impact the system beyond program termination.