|
From: James R. <jam...@gm...> - 2022-01-06 19:30:24
Attachments:
my_mmap.c
|
I have a program that definitely has a memory leak. I can see the memory usage of the program going up rapidly with htop until it gets killed for consuming too much memory. Yet this is the output from sudo valgrind -v --tool=memcheck --leak-check=full --show-reachable=yes --track-origins=yes --log-file=memcheck.log ./my_mmap ip enp3s0 192.168.1.254 : ==234971== ==234971== HEAP SUMMARY: ==234971== in use at exit: 235,528 bytes in 499 blocks ==234971== total heap usage: 499,999 allocs, 499,500 frees, 18,248,456 bytes allocated ==234971== ==234971== Searching for pointers to 499 not-freed blocks ==234971== Checked 4,186,197,696 bytes ==234971== ==234971== 235,528 bytes in 499 blocks are still reachable in loss record 1 of 1 ==234971== at 0x4843839: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==234971== by 0x48F06DD: __fopen_internal (iofopen.c:65) ==234971== by 0x48F06DD: fopen@@GLIBC_2.2.5 (iofopen.c:86) ==234971== by 0x10A2B6: main (my_mmap.c:466) ==234971== ==234971== LEAK SUMMARY: ==234971== definitely lost: 0 bytes in 0 blocks ==234971== indirectly lost: 0 bytes in 0 blocks ==234971== possibly lost: 0 bytes in 0 blocks ==234971== still reachable: 235,528 bytes in 499 blocks ==234971== suppressed: 0 bytes in 0 blocks ==234971== ==234971== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) I attach the code for the program in question. It requires an input file with one IP address per line. Any ideas why this memory leak is not being detected by valgrind? Or what the source of the memory leak could be? James Read |
|
From: James R. <jam...@gm...> - 2022-01-06 20:25:22
|
I think I found the problem. It seems valgrind doesn't detect memory leaks related to mmap. Why is this the case? On Thu, Jan 6, 2022 at 7:30 PM James Read <jam...@gm...> wrote: > I have a program that definitely has a memory leak. I can see the memory > usage of the program going up rapidly with htop until it gets killed for > consuming too much memory. Yet this is the output from sudo valgrind -v > --tool=memcheck --leak-check=full --show-reachable=yes --track-origins=yes > --log-file=memcheck.log ./my_mmap ip enp3s0 192.168.1.254 : > > ==234971== > ==234971== HEAP SUMMARY: > ==234971== in use at exit: 235,528 bytes in 499 blocks > ==234971== total heap usage: 499,999 allocs, 499,500 frees, 18,248,456 > bytes allocated > ==234971== > ==234971== Searching for pointers to 499 not-freed blocks > ==234971== Checked 4,186,197,696 bytes > ==234971== > ==234971== 235,528 bytes in 499 blocks are still reachable in loss record > 1 of 1 > ==234971== at 0x4843839: malloc (in > /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) > ==234971== by 0x48F06DD: __fopen_internal (iofopen.c:65) > ==234971== by 0x48F06DD: fopen@@GLIBC_2.2.5 (iofopen.c:86) > ==234971== by 0x10A2B6: main (my_mmap.c:466) > ==234971== > ==234971== LEAK SUMMARY: > ==234971== definitely lost: 0 bytes in 0 blocks > ==234971== indirectly lost: 0 bytes in 0 blocks > ==234971== possibly lost: 0 bytes in 0 blocks > ==234971== still reachable: 235,528 bytes in 499 blocks > ==234971== suppressed: 0 bytes in 0 blocks > ==234971== > ==234971== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > > I attach the code for the program in question. It requires an input file > with one IP address per line. > > Any ideas why this memory leak is not being detected by valgrind? Or what > the source of the memory leak could be? > > James Read > |
|
From: John R. <jr...@bi...> - 2022-01-06 23:35:04
|
> I think I found the problem. It seems valgrind doesn't detect memory leaks related to mmap. Why is this the case? A memory leak is a block that is allocated by malloc/calloc/realloc/reallocarray, not yet free()d, and with no in-process pointers to it. mmap is not malloc, and the result of mmap() cannot be a memory leak. Run "strace -e trace=mmap,mmap2,munmap,mremap ./my_app args..." or use a debugger to put a breakpoint on appropriate calls. |
|
From: Julian S. <jse...@gm...> - 2022-01-07 09:09:11
|
>> Any ideas why this memory leak is not being detected by valgrind? Because it's not really possible to do so. Consider the problem of knowing when an mmap-d page is no longer in use. Those pages are presumably managed by your app, in some way that is unknown to Valgrind/Memcheck, hence it has no way to know when a page is, logically speaking, leaked. By contrast, blocks in the normal malloc/free heap are "managed" by a simple protocol (calling malloc, then free) that Memcheck knows about. So it can figure out when a block is leaked by checking whether any pointers to it exist. Even then, that's a heuristic hack: you could conceivably represent a block address into two values, which, when added together, produce the address. Then Memcheck will believe the block to be leaked, even though you could regain access to it merely by adding the two values together. J |