1

I'm following this answer in order to find a leak in my program. I run valgrind with

valgrind --leak-check=full \
         --show-leak-kinds=all \
         --track-origins=yes \
         --verbose \
         --log-file=valgrind-out.txt \
         ./myExecutable

I compiled my program with -ggdb3 to get detailed leak information. Here's what I found:

HEAP SUMMARY:
==8705==     in use at exit: 52,761,451 bytes in 9,464 blocks
==8705==   total heap usage: 500,546 allocs, 491,082 frees, 136,352,927 bytes allocated
==8705== 
==8705== Searching for pointers to 9,464 not-freed blocks
==8705== Checked 201,910,184 bytes
==8705== 
==8705== 64 bytes in 4 blocks are possibly lost in loss record 1 of 11
==8705==    at 0x4844B3C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==8705== 
==8705== 168 bytes in 1 blocks are definitely lost in loss record 2 of 11
==8705==    at 0x4844BFC: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==8705== 
==8705== 184 bytes in 1 blocks are possibly lost in loss record 3 of 11
==8705==    at 0x4846D10: realloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==8705== 
==8705== 3,824 bytes in 57 blocks are still reachable in loss record 4 of 11
==8705==    at 0x4844B3C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==8705== 
==8705== 12,745 bytes in 8 blocks are still reachable in loss record 5 of 11
==8705==    at 0x4846D10: realloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==8705== 
==8705== 23,783 bytes in 126 blocks are possibly lost in loss record 6 of 11
==8705==    at 0x4844BFC: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==8705== 
==8705== 339,358 bytes in 58 blocks are possibly lost in loss record 7 of 11
==8705==    at 0x4846B0C: calloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==8705== 
==8705== 1,651,310 bytes in 6,986 blocks are still reachable in loss record 8 of 11
==8705==    at 0x484522C: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==8705== 
==8705== 2,411,391 bytes in 630 blocks are still reachable in loss record 9 of 11
==8705==    at 0x4846B0C: calloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==8705== 
==8705== 8,072,824 bytes in 1,557 blocks are still reachable in loss record 10 of 11
==8705==    at 0x4844BFC: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==8705== 
==8705== 40,245,800 bytes in 36 blocks are still reachable in loss record 11 of 11
==8705==    at 0x48458F4: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==8705== 
==8705== LEAK SUMMARY:
==8705==    definitely lost: 168 bytes in 1 blocks
==8705==    indirectly lost: 0 bytes in 0 blocks
==8705==      possibly lost: 363,389 bytes in 189 blocks
==8705==    still reachable: 52,397,894 bytes in 9,274 blocks
==8705==                       of which reachable via heuristic:
==8705==                         newarray           : 9,240 bytes in 45 blocks
==8705==                         multipleinheritance: 1,848 bytes in 4 blocks
==8705==         suppressed: 0 bytes in 0 blocks
==8705== 
==8705== ERROR SUMMARY: 7 errors from 6 contexts (suppressed: 0 from 0)
==8705== 
==8705== 2 errors in context 1 of 6:
==8705== Source and destination overlap in memcpy(0x49e0180, 0x49e0180, 208)
==8705==    at 0x484A080: __GI_memcpy (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==8705== 
==8705== ERROR SUMMARY: 7 errors from 6 contexts (suppressed: 0 from 0)

As you see, all the errors point to alloc functions in valgrind libraries. I cannot understand. Shouldn't it point to my executable?

Guerlando OCs
  • 1,886
  • 9
  • 61
  • 150
  • 1
    this may not be an option, but if you can use sanitizers, for me they give nicer error msg compared to valgrind. – NoSenseEtAl Sep 15 '19 at 01:07
  • Please provide a [mre]. In other words, show your program. Valgrind modifies the way memory allocation works, which may be the reason `/usr/lib/valgrind` is involved. – L. F. Sep 15 '19 at 04:11
  • @Guerlando OCs What about `-g` other than `-ggdb3`? – John Jun 06 '22 at 15:12

0 Answers0