Re: [Valgrind-users] Bug or feature - reported memory leak

[David C. <dcc...@ac...>]

On 12/7/2017 1:36 PM, Yusuf Pisan wrote:
>
> valgrind report memory as being reachable when I think it has been 
> properly freed in the below program. Is this a bug, a feature, a 
> misunderstanding of how to use delete by me?
>
> Thanks
>
> Yusuf
>
> ===================
>
> #include <iostream>
>
> using namespace std;
>
>
> int test() {
>
> int* p = new int[5];
>
> delete [] p;
>
> return 0;
>
> }
>
>
> int main() {
>
> test();
>
> return 0;
>
> }
>
>
> ===================
>
> $ uname -a
>
> Linux uw1-320-10 4.4.0-98-generic #121-Ubuntu SMP Tue Oct 10 14:24:03 
> UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
>
>
> $ valgrind --version
>
> valgrind-3.11.0
>
>
> $ g++ --version
>
> g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
>
>
> $ g++ -g -Wall -Wextra valgrind-example.cpp -o valgrind-example
>
>
> $ valgrind --leak-check=full --show-leak-kinds=all ./valgrind-example
>
> ==11597== Memcheck, a memory error detector
>
> ==11597== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
>
> ==11597== Using Valgrind-3.11.0 and LibVEX; rerun with -h for 
> copyright info
>
> ==11597== Command: ./valgrind-example
>
> ==11597==
>
> ==11597==
>
> ==11597== HEAP SUMMARY:
>
> ==11597== in use at exit: 72,704 bytes in 1 blocks
>
> ==11597== total heap usage: 2 allocs, 1 frees, 72,724 bytes allocated
>
> ==11597==
>
> ==11597== 72,704 bytes in 1 blocks are still reachable in loss record 
> 1 of 1
>
> ==11597==at 0x4C2DB8F: malloc (in 
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>
> ==11597==by 0x4EC3EFF: ??? (in 
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
>
> ==11597==by 0x40106B9: call_init.part.0 (dl-init.c:72)
>
> ==11597==by 0x40107CA: call_init (dl-init.c:30)
>
> ==11597==by 0x40107CA: _dl_init (dl-init.c:120)
>
> ==11597==by 0x4000C69: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so 
> <http://ld-2.23.so>)
>
> ==11597==
>
> ==11597== LEAK SUMMARY:
>
> ==11597==definitely lost: 0 bytes in 0 blocks
>
> ==11597==indirectly lost: 0 bytes in 0 blocks
>
> ==11597==possibly lost: 0 bytes in 0 blocks
>
> ==11597==still reachable: 72,704 bytes in 1 blocks
>
> ==11597== suppressed: 0 bytes in 0 blocks
>
> ==11597==
>
> ==11597== For counts of detected and suppressed errors, rerun with: -v
>
> ==11597== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>
> $
>
>

Look at the call chain - the still-reachable memory is allocated outside 
of your code.  It looks like the fault is in the C++ startup library 
that is provided by your Linux installation.  You could add a valgrind 
suppression to hide this "false positive" (as far as your program is 
concerned) but I've never bothered; I simply learn to ignore them.

-- 
     David Chapman      dcc...@ac...
     Chapman Consulting -- San Jose, CA
     EDA Software Developer, Expert Witness
     www.chapman-consulting-sj.com