|
From: Domenico P. <pan...@gm...> - 2021-12-15 08:34:29
|
Hi , I'm getting this message when I run : valgrind --leak-check=full ./MyProg ==4189== HEAP SUMMARY: ==4189== in use at exit: 192 bytes in 12 blocks ==4189== total heap usage: 21 allocs, 9 frees, 3,513 bytes allocated ==4189== ==4189== LEAK SUMMARY: ==4189== definitely lost: 0 bytes in 0 blocks ==4189== indirectly lost: 0 bytes in 0 blocks ==4189== possibly lost: 0 bytes in 0 blocks ==4189== still reachable: 192 bytes in 12 blocks ==4189== suppressed: 0 bytes in 0 blocks ==4189== Reachable blocks (those to which a pointer was found) are not shown. ==4189== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==4189== ==4189== For lists of detected and suppressed errors, rerun with: -s ==4189== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) I don't see errors but some still reachable blocks. Now, If i run : valgrind --leak-check=full --show-leak-kinds=all -s ./MyProg ==7209== HEAP SUMMARY: ==7209== in use at exit: 192 bytes in 12 blocks ==7209== total heap usage: 21 allocs, 9 frees, 3,513 bytes allocated ==7209== ==7209== 48 bytes in 6 blocks are still reachable in loss record 1 of 2 ==7209== at 0x48437B5: malloc (in /usr/libexec/valgrind/vgpreload_memcheck- amd64-linux.so) ==7209== by 0x4D9FC20: ??? (in /usr/lib64/libgcrypt.so.20.3.4) ==7209== by 0x4D2235C: ??? (in /usr/lib64/libgcrypt.so.20.3.4) ==7209== by 0x4D197E7: ??? (in /usr/lib64/libgcrypt.so.20.3.4) ==7209== by 0x4012A6D: call_init (in /usr/lib64/ld-linux-x86-64.so.2) ==7209== by 0x4012B6B: _dl_init (in /usr/lib64/ld-linux-x86-64.so.2) ==7209== by 0x40030C9: ??? (in /usr/lib64/ld-linux-x86-64.so.2) ==7209== ==7209== 144 bytes in 6 blocks are still reachable in loss record 2 of 2 ==7209== at 0x48437B5: malloc (in /usr/libexec/valgrind/vgpreload_memcheck- amd64-linux.so) ==7209== by 0x4D9FC20: ??? (in /usr/lib64/libgcrypt.so.20.3.4) ==7209== by 0x4D2235C: ??? (in /usr/lib64/libgcrypt.so.20.3.4) ==7209== by 0x4D197DA: ??? (in /usr/lib64/libgcrypt.so.20.3.4) ==7209== by 0x4012A6D: call_init (in /usr/lib64/ld-linux-x86-64.so.2) ==7209== by 0x4012B6B: _dl_init (in /usr/lib64/ld-linux-x86-64.so.2) ==7209== by 0x40030C9: ??? (in /usr/lib64/ld-linux-x86-64.so.2) ==7209== ==7209== LEAK SUMMARY: ==7209== definitely lost: 0 bytes in 0 blocks ==7209== indirectly lost: 0 bytes in 0 blocks ==7209== possibly lost: 0 bytes in 0 blocks ==7209== still reachable: 192 bytes in 12 blocks ==7209== suppressed: 0 bytes in 0 blocks ==7209== ==7209== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Could you help me to understand if I'm wronging something ? |
|
From: Floyd, P. <pj...@wa...> - 2021-12-15 09:05:26
|
> Could you help me to understand if I'm wronging something ? Hi This probably just means that libgcrypt is allocating some memory that it doesn't free. It's called in _dl_init, when the library is loaded) so it is most likely a one-off allocation and not dangerous. You have 2 choices. Either get debuginfo or a debug build for libgcrypt and find out exactly what is happening. Then you would need to either fix it yourself or get it fixed upstream. Alternatively (and much easier) is to use a suppression file. Run valgrind --leak-check=full --show-leak-kinds=all -s --gen-suppressions=all ./MyProg Copy and paste the suppresson file, editing it a bit to give a meaningful name and maybe reducing the calstack and/or using some wildcards (look at default.suppr for examples). Then run valgrind --leak-check=full --show-leak-kinds=all -s --suppressions=myprog.supp ./MyProg A+ Paul |
|
From: David C. <dcc...@ac...> - 2021-12-15 09:30:25
|
On 12/15/2021 12:34 AM, Domenico Panella wrote:
> Hi ,
>
> I'm getting this message when I run :
>
> valgrind --leak-check=full ./MyProg
>
> ==4189== HEAP SUMMARY:
> ==4189== in use at exit: 192 bytes in 12 blocks
> ==4189== total heap usage: 21 allocs, 9 frees, 3,513 bytes allocated
> ==4189==
> ==4189== LEAK SUMMARY:
> ==4189== definitely lost: 0 bytes in 0 blocks
> ==4189== indirectly lost: 0 bytes in 0 blocks
> ==4189== possibly lost: 0 bytes in 0 blocks
> ==4189== still reachable: 192 bytes in 12 blocks
> ==4189== suppressed: 0 bytes in 0 blocks
> ==4189== Reachable blocks (those to which a pointer was found) are not shown.
> ==4189== To see them, rerun with: --leak-check=full --show-leak-kinds=all
> ==4189==
> ==4189== For lists of detected and suppressed errors, rerun with: -s
> ==4189== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>
> I don't see errors but some still reachable blocks.
> Now, If i run :
>
> valgrind --leak-check=full --show-leak-kinds=all -s ./MyProg
>
> ==7209== HEAP SUMMARY:
> ==7209== in use at exit: 192 bytes in 12 blocks
> ==7209== total heap usage: 21 allocs, 9 frees, 3,513 bytes allocated
> ==7209==
> ==7209== 48 bytes in 6 blocks are still reachable in loss record 1 of 2
> ==7209== at 0x48437B5: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-
> amd64-linux.so)
> ==7209== by 0x4D9FC20: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
> ==7209== by 0x4D2235C: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
> ==7209== by 0x4D197E7: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
> ==7209== by 0x4012A6D: call_init (in /usr/lib64/ld-linux-x86-64.so.2)
> ==7209== by 0x4012B6B: _dl_init (in /usr/lib64/ld-linux-x86-64.so.2)
> ==7209== by 0x40030C9: ??? (in /usr/lib64/ld-linux-x86-64.so.2)
> ==7209==
> ==7209== 144 bytes in 6 blocks are still reachable in loss record 2 of 2
> ==7209== at 0x48437B5: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-
> amd64-linux.so)
> ==7209== by 0x4D9FC20: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
> ==7209== by 0x4D2235C: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
> ==7209== by 0x4D197DA: ??? (in /usr/lib64/libgcrypt.so.20.3.4)
> ==7209== by 0x4012A6D: call_init (in /usr/lib64/ld-linux-x86-64.so.2)
> ==7209== by 0x4012B6B: _dl_init (in /usr/lib64/ld-linux-x86-64.so.2)
> ==7209== by 0x40030C9: ??? (in /usr/lib64/ld-linux-x86-64.so.2)
> ==7209==
> ==7209== LEAK SUMMARY:
> ==7209== definitely lost: 0 bytes in 0 blocks
> ==7209== indirectly lost: 0 bytes in 0 blocks
> ==7209== possibly lost: 0 bytes in 0 blocks
> ==7209== still reachable: 192 bytes in 12 blocks
> ==7209== suppressed: 0 bytes in 0 blocks
> ==7209==
> ==7209== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>
> Could you help me to understand if I'm wronging something ?
A system library (in this case libgcrypt.so) is allocating memory but
not releasing it (keeping the memory for the life of the program).
There are pointers to those memory blocks, so strictly speaking they are
not lost memory. Even this is not the fault of your code, so don't
worry about it. Your code does not have a memory leak.
--
David Chapman dcc...@ac...
Chapman Consulting -- San Jose, CA
EDA Software Developer, Expert Witness
www.chapman-consulting-sj.com
2018-2019 Chair, IEEE Consultants' Network of Silicon Valley
|
|
From: Domenico P. <pan...@gm...> - 2021-12-15 09:51:37
|
In data mercoledì 15 dicembre 2021 10:15:51 CET, David Chapman ha scritto: Ok. Thanks > On 12/15/2021 12:34 AM, Domenico Panella wrote: > > Hi , > > > > I'm getting this message when I run : > > > > valgrind --leak-check=full ./MyProg > > > > ==4189== HEAP SUMMARY: > > ==4189== in use at exit: 192 bytes in 12 blocks > > ==4189== total heap usage: 21 allocs, 9 frees, 3,513 bytes allocated > > ==4189== > > ==4189== LEAK SUMMARY: > > ==4189== definitely lost: 0 bytes in 0 blocks > > ==4189== indirectly lost: 0 bytes in 0 blocks > > ==4189== possibly lost: 0 bytes in 0 blocks > > ==4189== still reachable: 192 bytes in 12 blocks > > ==4189== suppressed: 0 bytes in 0 blocks > > ==4189== Reachable blocks (those to which a pointer was found) are not > > shown. ==4189== To see them, rerun with: --leak-check=full > > --show-leak-kinds=all ==4189== > > ==4189== For lists of detected and suppressed errors, rerun with: -s > > ==4189== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > > > > I don't see errors but some still reachable blocks. > > Now, If i run : > > > > valgrind --leak-check=full --show-leak-kinds=all -s ./MyProg > > > > ==7209== HEAP SUMMARY: > > ==7209== in use at exit: 192 bytes in 12 blocks > > ==7209== total heap usage: 21 allocs, 9 frees, 3,513 bytes allocated > > ==7209== > > ==7209== 48 bytes in 6 blocks are still reachable in loss record 1 of 2 > > ==7209== at 0x48437B5: malloc (in > > /usr/libexec/valgrind/vgpreload_memcheck- amd64-linux.so) > > ==7209== by 0x4D9FC20: ??? (in /usr/lib64/libgcrypt.so.20.3.4) > > ==7209== by 0x4D2235C: ??? (in /usr/lib64/libgcrypt.so.20.3.4) > > ==7209== by 0x4D197E7: ??? (in /usr/lib64/libgcrypt.so.20.3.4) > > ==7209== by 0x4012A6D: call_init (in /usr/lib64/ld-linux-x86-64.so.2) > > ==7209== by 0x4012B6B: _dl_init (in /usr/lib64/ld-linux-x86-64.so.2) > > ==7209== by 0x40030C9: ??? (in /usr/lib64/ld-linux-x86-64.so.2) > > ==7209== > > ==7209== 144 bytes in 6 blocks are still reachable in loss record 2 of 2 > > ==7209== at 0x48437B5: malloc (in > > /usr/libexec/valgrind/vgpreload_memcheck- amd64-linux.so) > > ==7209== by 0x4D9FC20: ??? (in /usr/lib64/libgcrypt.so.20.3.4) > > ==7209== by 0x4D2235C: ??? (in /usr/lib64/libgcrypt.so.20.3.4) > > ==7209== by 0x4D197DA: ??? (in /usr/lib64/libgcrypt.so.20.3.4) > > ==7209== by 0x4012A6D: call_init (in /usr/lib64/ld-linux-x86-64.so.2) > > ==7209== by 0x4012B6B: _dl_init (in /usr/lib64/ld-linux-x86-64.so.2) > > ==7209== by 0x40030C9: ??? (in /usr/lib64/ld-linux-x86-64.so.2) > > ==7209== > > ==7209== LEAK SUMMARY: > > ==7209== definitely lost: 0 bytes in 0 blocks > > ==7209== indirectly lost: 0 bytes in 0 blocks > > ==7209== possibly lost: 0 bytes in 0 blocks > > ==7209== still reachable: 192 bytes in 12 blocks > > ==7209== suppressed: 0 bytes in 0 blocks > > ==7209== > > ==7209== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > > > > Could you help me to understand if I'm wronging something ? > > A system library (in this case libgcrypt.so) is allocating memory but > not releasing it (keeping the memory for the life of the program). > There are pointers to those memory blocks, so strictly speaking they are > not lost memory. Even this is not the fault of your code, so don't > worry about it. Your code does not have a memory leak. |