Understanding Valgrind Exit

Question

I am new to Linux. How can I interpret the following conclusion from

valgrind --tool=memcheck --leak-check=yes ./main 

It says some blocks are lost. How can I hide memory leaks.

 ==2599== HEAP SUMMARY: ==2599== in use at exit: 17,327 bytes in 55 blocks ==2599== total heap usage: 180,597 allocs, 180,542 frees, 15,787,989,675 bytes allocated ==2599== ==2599== 9 bytes in 1 blocks are definitely lost in loss record 5 of 19 ==2599== at 0x4025BD3: malloc (vg_replace_malloc.c:236) ==2599== by 0x41E546F: strdup (strdup.c:43) ==2599== by 0x804BA2A: Schema::Schema(char*, char*) (Schema.cc:86) ==2599== by 0x804AD78: CNF::GrowFromParseTree(AndList*, Schema*, Record&) (Comparison.cc:606) ==2599== by 0x804EE52: main (main.cc:28) ==2599== ==2599== 10 bytes in 2 blocks are definitely lost in loss record 6 of 19 ==2599== at 0x4025BD3: malloc (vg_replace_malloc.c:236) ==2599== by 0x41E546F: strdup (strdup.c:43) ==2599== by 0x804BB84: Schema::Schema(char*, char*) (Schema.cc:115) ==2599== by 0x804AD78: CNF::GrowFromParseTree(AndList*, Schema*, Record&) (Comparison.cc:606) ==2599== by 0x804EE52: main (main.cc:28) ==2599== ==2599== 13 bytes in 1 blocks are definitely lost in loss record 9 of 19 ==2599== at 0x4025BD3: malloc (vg_replace_malloc.c:236) ==2599== by 0x41E546F: strdup (strdup.c:43) ==2599== by 0x804BA2A: Schema::Schema(char*, char*) (Schema.cc:86) ==2599== by 0x804EDF4: main (main.cc:23) ==2599== ==2599== 13 bytes in 1 blocks are definitely lost in loss record 10 of 19 ==2599== at 0x4025BD3: malloc (vg_replace_malloc.c:236) ==2599== by 0x41E546F: strdup (strdup.c:43) ==2599== by 0x804BA2A: Schema::Schema(char*, char*) (Schema.cc:86) ==2599== by 0x804EEA4: main (main.cc:37) ==2599== ==2599== 188 bytes in 16 blocks are definitely lost in loss record 16 of 19 ==2599== at 0x4025BD3: malloc (vg_replace_malloc.c:236) ==2599== by 0x41E546F: strdup (strdup.c:43) ==2599== by 0x804BB84: Schema::Schema(char*, char*) (Schema.cc:115) ==2599== by 0x804EDF4: main (main.cc:23) ==2599== ==2599== 188 bytes in 16 blocks are definitely lost in loss record 17 of 19 ==2599== at 0x4025BD3: malloc (vg_replace_malloc.c:236) ==2599== by 0x41E546F: strdup (strdup.c:43) ==2599== by 0x804BB84: Schema::Schema(char*, char*) (Schema.cc:115) ==2599== by 0x804EEA4: main (main.cc:37) ==2599== ==2599== LEAK SUMMARY: ==2599== definitely lost: 421 bytes in 37 blocks ==2599== indirectly lost: 0 bytes in 0 blocks ==2599== possibly lost: 0 bytes in 0 blocks ==2599== still reachable: 16,906 bytes in 18 blocks ==2599== suppressed: 0 bytes in 0 blocks ==2599== Reachable blocks (those to which a pointer was found) are not shown. ==2599== To see them, rerun with: --leak-check=full --show-reachable=yes ==2599== ==2599== For counts of detected and suppressed errors, rerun with: -v ==2599== ERROR SUMMARY: 6 errors from 6 contexts (suppressed: 19 from 8) 

Answer 1

The output shows a fairly simple stack for which a leak is allocated (and lost, that is, pointers that remain), on lines 86 and 115 of Schema.cc (calling strdup )

Answer 2

From opengroup Description of strdup () :

The strdup () function returns a pointer to a new line, which is a duplicate of the line pointed to by s1. The returned pointer can be passed to free (). Returns a null pointer if a new line cannot be created.

In short, strdup() calls malloc() . You will need free() to get the string when you are done with it. Although, since you are using C ++, I would highly recommend std::string if possible. Remember that if you really need the C-equivalent of string.c_str() , it will get it for you.