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

[Julian S. <js...@ac...>]

Thanks to you both.  I've added this to the FAQ.

J


On Saturday 26 April 2003 3:08 pm, Bastien Chevreux wrote:
> 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.