Valgrind doesn't detect any memory leaks. How safe is that?

Question

I have run my code through valgrind with these results:

==4492== Memcheck, a memory error detector
==4492== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==4492== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==4492== Command: ./mem
==4492== Parent PID: 4455
==4492==
==4492==
==4492== HEAP SUMMARY:
==4492== in use at exit: 0 bytes in 0 blocks
==4492== total heap usage: 19,595,342 allocs, 19,595,342 frees, 27,194,270 bytes allocated ==4492==
==4492== All heap blocks were freed -- no leaks are possible
==4492==
==4492== For counts of detected and suppressed errors, rerun with: -v
==4492== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

However, while the code is running, I see a small, steady increase in the memory used by the program. How sure can I be with that result?

I run valgrind using:

valgrind --track-origins=yes --leak-check=yes
    --tool=memcheck --read-var-info=yes --log-file=error.txt`

and I compile the program using the -g and the -march=core2 tags.

Answer 1

You need to distinguish between memory leaks (memory that was allocated, but you lost all references to) and memory hogs (memory that was allocated, that you keep references to, but forgot to deallocate).

The later one can not be detected by valgrind, since valgrind doesn't know you did not want to use it anymore.

To get some statistics about your programs memory usage, you can use the massif tool of valgrind, which will show you in more detail where your memory gets allocated. This might be helpful in finding memory hogs.

Answer 2

A small increase in memory usage is not necessarily something to worry about - it may be that your program is ramping up and will peak at some point. Without knowing the logic of that application, it's hard to tell. However, it's adamant that all allocated blocks were freed and it's usually pretty good.

You may want to consider letting it run for longer, increasing the work it has to do somehow (again this depends on the application) to see if it ever peaks or continues to rise forever (or until it runs out of virtual memory, anyway).

I'd also look at those last two lines:

==4492== For counts of detected and suppressed errors, rerun with: -v
==4492== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4) 

You may want to run it with -v just to check what those suppressions were. They may be nothing but it doesn't hurt to look into it.

Answer 3

Do you see memory usage increasing with a tool like top? Depending on the behavior of your program, if you allocate and free memory continually you may introduce fragmentation that causes the address space to grow. If you let the process run long enough it may stabilize and stop growing.

Answer 4

valgrind can detect memory leaks, but not poor usage of memory. It's possible that a bug in your code is continually allocating memory for no apparent reason, and that defensive code is then cleaning it all up afterwards anyway.

That said, I wouldn't trust your mechanism for determining your process's memory usage, either. There's a lot that goes on behind the scenes: caching, for one.

I'd call this "inconclusive".