Re: [Valgrind-users] "Reachable" memory, where's the bug (g++, STL, valgrind)?

[David E. <da...@2g...>]

On Wed, 2003-04-09 at 15:45, Bastien Chevreux wrote:
> Hello there,
> 
> I have serious troubles with possible memory leaks in programs heavily
> using the STL. I am not able to tell whether it is a problem with the
> compiler, the STL or wrong valgrind output, so I'll start here before
> filing in a gcc bug report.
> 
> One of my programs grew larger and larger without I knew why, so took
> valgrind to look and started building testcases to find out what was
> happening. I have a SuSE 8.1 distribution, that's kernel 2.4.x,
> glibc2.2 and gcc version 3.2
> 
> Consider this test case example:
> 
> -------------------------------------------------------
> #include <vector>
> #include <ext/hash_map>
> using namespace __gnu_cxx;
> 
> void f1()
> {
>   int n=42;
>   vector<int> v;
>   for(int i=0; i<1000000; i++) v.push_back(n);
> }
> 
> int main(){
>   f1();
>   return 0;
> }
> ----------------------------------------------------------
> 
> g++ -g -o test test.C 
> 
> and then 
> 
> valgrind --leak-resolution=high --num-callers=20 --show-reachable=yes --leak-check=yes ./test
> 
> I will get the following summary:
> 
> ----------------------------------------------------------
> ==16880== LEAK SUMMARY:
> ==16880==    definitely lost: 16 bytes in 1 blocks.
> ==16880==    possibly lost:   0 bytes in 0 blocks.
> ==16880==    still reachable: 6912 bytes in 4 blocks.
> ----------------------------------------------------------
> 
> The number which troubles me ist the bytes that are still
> reachable. Here's, the detail:
> 
> ----------------------------------------------------------
> ==19169== 6848 bytes in 3 blocks are still reachable in loss record 3 of 3
> ==19169==    at 0x4015DE3B: __builtin_new (vg_clientfuncs.c:129)
> ==19169==    by 0x4015DE76: operator new(unsigned) (vg_clientfuncs.c:142)
> ==19169==    by 0x40278E00: std::__default_alloc_template<true, 0>::_S_chunk_alloc(unsigned, int&) (in /usr/lib/libstdc++.so.5.0.0)
> ==19169==    by 0x40278D1C: std::__default_alloc_template<true, 0>::_S_refill(unsigned) (in /usr/lib/libstdc++.so.5.0.0)
> ==19169==    by 0x402788EF: std::__default_alloc_template<true, 0>::allocate(unsigned) (in /usr/lib/libstdc++.so.5.0.0)
> ==19169==    by 0x8049008: std::__simple_alloc<int, std::__default_alloc_template<true, 0> >::allocate(unsigned) (/usr/include/g++/bits/stl_alloc.h:224)
> ==19169==    by 0x8048D7E: std::_Vector_alloc_base<int, std::allocator<int>, true>::_M_allocate(unsigned) (/usr/include/g++/bits/stl_vector.h:121)
> ==19169==    by 0x8048A45: std::vector<int, std::allocator<int> >::_M_insert_aux(__gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >, int const&) (/usr/include/g++/bits/stl_vector.h:898)
> ==19169==    by 0x804884C: std::vector<int, std::allocator<int> >::push_back(int const&) (/usr/include/g++/bits/stl_vector.h:496)
> ==19169==    by 0x80486A1: f1() (test2.C:10)
> ==19169==    by 0x80487A2: main (test2.C:21)
> ==19169==    by 0x403094A1: __libc_start_main (in /lib/libc.so.6)
> ==19169==    by 0x8048580: (within /home/bach/work/assembly/htga/src/progs/test)
> ----------------------------------------------------------
> 
> Regarding the program above, I sincerely do think that there should be
> no leak at all, even not in "reachable" parts.
> 
> Now, a few bytes don't hurt. Unfortunately, when I let run my real
> program, here's what I get (for really small data sets):
> 
> ----------------------------------------------------------
> ==698== LEAK SUMMARY:
> ==698==    definitely lost: 24825 bytes in 3492 blocks.
> ==698==    possibly lost:   1398 bytes in 3 blocks.
> ==698==    still reachable: 1125492 bytes in 65 blocks.
> ----------------------------------------------------------
> 
> (please note that I don't care about the that the definitely and
> possibly lost numbers, these I can trace back to real oversights in my
> code.)
> 
> The "still reachable" 1M number is about 40 times greater than the
> other two numbers added together and I have the distinct impression
> that the memory is really eaten away somewhere: 
>  1) all valgrind detail messages are more or less similar to the one of
>     the test case above, all have something to do with containers
>  2) putting a "while(1)" loop at a distinctive point in my program
>     where everything should have been more or less freed after some
>     heavy computation (using about any existing STL container type
>     that exists with dozens of different classes) gives me remaining
>     memory footprints of >1G (yes, that's gigabyte).
> 
> Now my question: any idea where to start searching? is valgrind at
> fault (which I don't think, but one never knows)? the gnu STL? the gnu
> g++ compiler?
> 
> Any suggestion welcome. 

My guess is that the STL allocator keeps the memory around. What happens
if you call f1() several times in main()?

-- 
-\- David Eriksson -/-                              www.2GooD.nu
 
"I personally refuse to use inferior tools because of ideology."
                                                - Linus Torvalds