Valgrind errors

Question

I have recently developed a habit of running all of my programs through valgrind to check for memory leaks, but most of its results have been a bit cryptic for me.

For my latest run, valgrind -v gave me:

All heap blocks were freed -- no leaks are possible

That means my program's covered for memory leaks, right?

So what does this error mean? Is my program not reading certain memory blocks correctly?

ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 14 from 9)

1 errors in context 1 of 1:
Invalid read of size 4
   at 0x804885B: findPos (in /home/a.out)
   by 0xADD918: start_thread (pthread_create.c:301)
   by 0xA26CCD: clone (clone.S:133)
 Address 0x4a27108 is 0 bytes after a block of size 40 alloc'd
   at 0x4005BDC: malloc (vg_replace_malloc.c:195)
   by 0x804892F: readInput (in /home/a.out)
   by 0xADD918: start_thread (pthread_create.c:301)
   by 0xA26CCD: clone (clone.S:133)

used_suppression:     14 dl-hack3-cond-1

Also, what are the so-called "suppressed" errors here?

Answer 1

1. Yes, you are greatly covered, don't think that valgrind easily can miss a leak in user code
2. your error means that you probably have a +1 error in indexing an array variable. the lines that valgrind tell you should be accurate, so you should easily find that, provided you compile all your code with -g
3. suppressed errors are usually from system libraries, which sometimes have small leaks or undectable things like the state variables of threads. your manual page should list the suppression file that is used by default

Answer 2

This seems obvious ... but it might be worth pointing out that the "no leaks are possible" message does not mean that your program cannot leak; it just means that it did not leak in the configuration under which it was tested.

If I run the following with valgrind with no command line parameters, it informs me that no leaks are possible. But it does leak if I provide a command line parameter.

int main( int argc, char* argv[] )
{
   if ( argc > 1 )
      malloc( 5 );
   printf( "Enter any command line arg to cause a leak\n" );
}

Answer 3

Checking for memory leaks is one reason to use valgrind, but I'd say a better reason is to find more serious errors in your code, such as using an invalid array subscript or dereferencing an uninitialized pointer or a pointer to freed memory.

It's good if valgrind tells you that the code paths you exercised while running valgrind didn't result in memory leaks, but don't let that cause you to ignore reports of more serious errors, such as the one you're seeing here.

As other have suggested, rerunning valgrind after compiling with debug information (-g) would be a good next step.