|
From: David E. <da...@2g...> - 2003-04-09 17:37:55
|
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
|