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

[Bastien C. <ba...@ch...>]

On Wednesday 09 April 2003 19:37, you wrote:
> My guess is that the STL allocator keeps the memory around. What happen=
s
> if you call f1() several times in main()?

No change, at least for this small example. But I continued to play a bit=
 with=20
containers my program uses and came out with this gem:

------------------------------------------------
#include<iostream>
#include<deque>
#include<set>
using namespace std;

void f1(int ic)
{
  set<char> n;
  for(char c=3D'a'; c < 'z'; c++) n.insert(c);

  deque<set<char> > v;
  for(int i=3D0; i<ic; i++) v.push_back(n);
}

int main(){
  f1(1000);
  cout << "The memory footprint ..." << endl;
  f1(20000);
  cout << "... should be ..." << endl;
  f1(50000);
  cout << "... near zero exactly now! (it isn't *sigh*)" << endl;

  //while(1);

  return 0;
}
------------------------------------------------

Everyone's invited to let this run on their system ...

------------------------------------------------
=3D=3D13669=3D=3D LEAK SUMMARY:
=3D=3D13669=3D=3D    definitely lost: 16 bytes in 1 blocks.
=3D=3D13669=3D=3D    possibly lost:   0 bytes in 0 blocks.
=3D=3D13669=3D=3D    still reachable: 32568232 bytes in 127 blocks.
=3D=3D13669=3D=3D         suppressed: 0 bytes in 0 blocks.
------------------------------------------------

=2E.. and play with it: the numbers get lower when stopping after f1(2000=
) or=20
f1(20000)). Best thing is, when one uncomments the while(1); statement th=
e=20
memory footprint is around 80M (where it shouldn't be much greater than t=
he=20
size of the executable).

I digged the news a bit and found this:=20

http://groups.google.com/groups?hl=3Den&lr=3D&ie=3DUTF-8&oe=3Dutf-8&frame=
=3Dright&th=3D432bcc216e83d78f&seekm=3Dslrnaa3v4d.lt.mixtim_nospam%40taco=
=2Emixtim.ispwest.com#link3

Here's one interesting part:

> The default allocator for many c++ standard libraries (such as the one =
that
> ships with gcc) never actually "frees" memory. It just adds the memory =
back
> to a pool for later use. So, if you allocate a map that contains 80 MB
> worth of data and then destroy the map, your application still has that=
 80
> MB allocated and will until your program exits.

On the other hand, after the program exited, valgrind should not find any=
=20
leaks (the STL pool should have been freed, right?). Any ideas?

So the STL is to 'blame'. The description of the pool behaviour should go=
 into=20
the FAQ of valgrind, though, I'm sure other people tripped (are tripping,=
=20
will trip) over that too.

And now for something completely related (but going off topic): is there =
any=20
way to "flush" that pool?=20

Regards,
        Bastien

PS: Did I already thank the valgrind author? No? I longed for a tool like=
 that=20
for Linux since I first worked with purify on a SUN. Thanks a lot.

--=20
        -- The universe has its own cure for stupidity. --
         -- Unfortunately, it doesn't always apply it. --