Valgrind reporting memory definitely lost without errors

Question

I am testing C code for memory leaks and can't seem to find the source of the leaks because there are 0 errors. Valgrind reports that there is a (quite significant) memory leak:

==30492== Memcheck, a memory error detector
==30492== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==30492== Using Valgrind-3.14.0.GIT and LibVEX; rerun with -h for copyright 
info
==30492== Command: ./a.out --leak-check=full --track-origins=yes
==30492== 
(This is where the input and output cases are displayed, which are a lot)
==30492== 
==30492== HEAP SUMMARY:
==30492==     in use at exit: 39,155 bytes in 167 blocks
==30492==   total heap usage: 380 allocs, 213 frees, 53,426 bytes allocated
==30492== 
==30492== LEAK SUMMARY:
==30492==    definitely lost: 20,480 bytes in 2 blocks
==30492==    indirectly lost: 2,064 bytes in 1 blocks
==30492==      possibly lost: 0 bytes in 0 blocks
==30492==    still reachable: 348 bytes in 9 blocks
==30492==         suppressed: 16,263 bytes in 155 blocks
==30492== Rerun with --leak-check=full to see details of leaked memory
==30492== 
==30492== For counts of detected and suppressed errors, rerun with: -v
==30492== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

The code is written in a few files and consists of hundreds of lines, so posting it here would probably be a bit much. Could anyone explain what could be the problem here? Or would you need to see the actual code to give an answer? I can find only little documentation on valgrind and am quite stuck here.

(valgrind suggests to rerun with --leak-check=full, but that is what I did to get this output)

You can perhaps remove parts of your program to see if they are responsible for this, until you have something small enough to show here. — Arndt Jonasson, Mar 20 '18 at 21:58
@sturcotte06 I added --track-origins=yes and adjusted the output. — fabero, Mar 20 '18 at 22:00
@Pablo This is the complete output (without input output cases for brevity) — fabero, Mar 20 '18 at 22:01
@ArndtJonasson That would be quite difficult as the program handles expression trees and all parts are needed — fabero, Mar 20 '18 at 22:02
Did you compile your code with `-g`? Compiler it with `-g` and rerun valgrind. — Pablo, Mar 20 '18 at 22:03
Could it be that you are adding `--leak-check=full` at the end of the command line? In that case valgrind will think that this is an argument for the program it's testing, not for itself. Did you run `valgrind --leak-check=full ./your_program arg1 arg2...`? — Pablo, Mar 20 '18 at 22:08
@Pablo Ah yes that was probably the problem! Thank you very much! Now it found three errors (that I also do not understand, but at least this is some progress :-) )! — fabero, Mar 20 '18 at 22:13
@sturcotte06 `--track-origins=yes` is for tracking sources of uninitialized data, it has nothing to do with memory leaks. `--leak-check=full` is what he needs. — Miroslav Franc, Mar 20 '18 at 22:15
Valgrind is saying that somewhere in your code you have malloc'ed some memory that you have never freed . Doing just that might not be an issue in itself, and valgrind does not count it as errors. WHen you ran valgrind with the --leak.check=full, the important part is in the "(This is where the input and output cases are displayed, which are a lot)" part that you left out. This will show you where you allocate the memory that you have not freed, and you need to figure out if that is a problem or not. As always, start with the 1. item, fix it, re-run valgrind and fix the 1.item .... — nos, Mar 20 '18 at 23:03

score 1 · Accepted Answer · answered Mar 23 '18 at 23:47

It is possible to get false positives (e.g. in shared library initializers, or things like libcrypto.so which does leak some allocation).

However, you should always check - most likely you're forgetting some allocation.

In your output, we can see:

 Command: ./a.out --leak-check=full --track-origins=yes`

This indicates you've invoked valgrind with:

valgrind ./a.out --leak-check=full --track-origins=yes

You should use this:

valgrind --leak-check=full --track-origins=yes ./a.out

If you find a leak (or other diagnostic) that you cannot control because it's internal to a third-party library, you can make a suppression file

Thanks, this was indeed the solution. The errors turned out to be caused by valgrind not being supported as much on OS X as on Linux (https://stackoverflow.com/questions/34573039/possible-memory-leak-valgrind-in-osx-el-capitan/35592274). — fabero, Mar 25 '18 at 14:38

Valgrind reporting memory definitely lost without errors

1 Answers1