Re: [Valgrind-users] Why doesn't freed C++ string memory when program exits?

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

On Saturday 26 April 2003 11:58, Julian Seward wrote:
> Yes it is definitely one for the recently-expanded FAQ.  Some more
> info (or the complete FAQ entry :) would be helpful.  Specifically,
> can you say how to disable the STL's memory pooling, since that will
> be the next thing that people ask having read the below.

Hi there,

I took Philippes answer and put in some additional information I had. See 
below.

On a related sidenote, I have the soon to be 3.3, and using GLIBCPP_FORCE_NEW 
does not work for me (while -D__USE_MALLOC already produces compiler errors). 
Tested this with that small program:

------------------------------------------------
#include<iostream>
#include<deque>
#include<set>
using namespace std;
void f1(int ic)
{
  set<char> n;
  for(char c='a'; c < 'z'; c++) n.insert(c);
  deque<set<char> > v;
  for(int i=0; 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;
}
------------------------------------------------

And made a "setenv GLIBCPP_FORCE_NEW 1" before running the program -> still 
30M memory imprint at the while loop. Anyone else seen this?

Here's my proposal for the FAQ:

Q14.  My program uses the C++ STL and string classes. Valgrind reports 'still 
reachable' memory leaks involving these classes at the exit of the program, 
but there should be none?!

A14.  First of all: relax, it's probably not a bug, but a feature. Many 
implementations of the C++ standard libraries use own memory pool allocators. 
Memory for quite a number of destructed objects is not immediately freed and 
given back to the OS, but kept in the pool(s) for later re-use. The fact that 
the pools are not freed at the exit() of the program trigger valgrind. The 
behaviour not to free pools at the exit() could be called a bug of the 
library though.

Using gcc, you can force the STL to use malloc and to free memory as soon as 
possible by globally disabling memory caching. Beware! Doing so will probably 
slow down your program, sometimes drastically.

- With gcc 2.91, 2.95, 3.0 and 3.1 compile all source using the STL with
  -D__USE_MALLOC. Beware! This is removed from gcc starting with version 3.3.   
- With 3.2.2 and later, you should export the environment variable
  GLIBCPP_FORCE_NEW before running your program.

There are other ways to disable memory pooling: using the malloc_alloc 
template with your objects (not portable, but should work for gcc) or even 
writing your own memory allocators. But all this goes beyond the scope of 
this FAQ. Start with reading
      http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#3
if you absolutely want to do that. But beware:
  1) there are currently changes underway for gcc which are not totally 
reflected in the docs right now.
  2) allocators belong to the more messy parts of the STL and people went at 
great lengths to make it portable across platforms. Chances are good that 
your solution will work on your platform, but not on others.

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