|
From: Bastien C. <ba...@ch...> - 2003-04-09 22:10:20
|
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. --
|