valgrind-users

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

[Lee, H. <HJ...@ec...>]

Hi,
 
If I use string type for example ---> string a("Hello, world"), the memory
allocated for string isn't freed when program exit.
valgrand reported it is not-freed block. Here is valgrind reports logs.
Why is it not freed when program exits? I am using RH6.2.
----------------
==2264== Addrcheck, a fine-grained address checker for x86-linux.
==2264== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
==2264== Using valgrind-1.9.5, a program instrumentation system for
x86-linux.
==2264== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==2264== 
==2264== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==2264== malloc/free: in use at exit: 1280 bytes in 1 blocks.
==2264== malloc/free: 1 allocs, 0 frees, 1280 bytes allocated.
==2264== For counts of detected errors, rerun with: -v
==2264== searching for pointers to 1 not-freed blocks.
==2264== checked 3490188 bytes.
==2264== 
==2264== 1280 bytes in 1 blocks are still reachable in loss record 1 of 1
==2264==    at 0x4014D4C8: malloc (in /usr/local/lib/valgrind/valgrind.so)
==2264==    by 0x4021B96F: __default_alloc_template<true,
0>::chunk_alloc(unsigned int, int &) (in
/usr/lib/libstdc++-2-libc6.1-1-2.9.0.so)
==2264==    by 0x4021BA28: __default_alloc_template<true,
0>::refill(unsigned int) (in /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so)
==2264==    by 0x402140F2: basic_string<char, string_char_traits<char>,
__default_alloc_template<true, 0> >::replace(unsigned int, unsigned int,
char const *, unsigned int) (in /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so)
==2264==    by 0x402169B7: basic_string<char, string_char_traits<char>,
__default_alloc_template<true, 0> >::basic_string(char const *) (in
/usr/lib/libstdc++-2-libc6.1-1-2.9.0.so)
==2264==    by 0x804A1D4: main (str_test.cpp:19)
==2264==    by 0x402729CA: __libc_start_main (in /lib/libc-2.1.3.so)
==2264==    by 0x804A130: ??? (/usr/include/g++-2/stl_alloc.h:533)
==2264== 
==2264== LEAK SUMMARY:
==2264==    definitely lost: 0 bytes in 0 blocks.
==2264==    possibly lost:   0 bytes in 0 blocks.
==2264==    still reachable: 1280 bytes in 1 blocks.
==2264==         suppressed: 0 bytes in 0 blocks.
------------------
 
HJ

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

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

On Saturday 26 April 2003 02:03, Lee, HJ wrote:
> If I use string type for example ---> string a("Hello, world"), the memory
> allocated for string isn't freed when program exit.
> valgrand reported it is not-freed block. Here is valgrind reports logs.
> Why is it not freed when program exits? I am using RH6.2.

The thread ""Reachable" memory, where's the bug (g++, STL, valgrind)?" might 
help you there. In short: the C++ STL and string function have their own 
memory pooling mechanisms to gain speed. The memory of these objects is not 
'freed' per se when they are destructed, but returned to the internal memory 
pool and will be reused for other objects created. It's these pool fragments 
(which are not freed by the C++ library before exit) that valgrind chokes on.

While you can minimise this behaviour with the STL by providing your own 
allocators (not recommended, slows down execution speed terribly on some 
systems), I am not aware of similar mechanisms for the string classes.

Salut,
      Bastien

PS: This is _definitively_ something for the FAQ.

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

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

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

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.

Thx

J

On Saturday 26 April 2003 10:42 am, Bastien Chevreux wrote:
> On Saturday 26 April 2003 02:03, Lee, HJ wrote:
> > If I use string type for example ---> string a("Hello, world"), the
> > memory allocated for string isn't freed when program exit.
> > valgrand reported it is not-freed block. Here is valgrind reports logs.
> > Why is it not freed when program exits? I am using RH6.2.
>
> The thread ""Reachable" memory, where's the bug (g++, STL, valgrind)?"
> might help you there. In short: the C++ STL and string function have their
> own memory pooling mechanisms to gain speed. The memory of these objects is
> not 'freed' per se when they are destructed, but returned to the internal
> memory pool and will be reused for other objects created. It's these pool
> fragments (which are not freed by the C++ library before exit) that
> valgrind chokes on.
>
> While you can minimise this behaviour with the STL by providing your own
> allocators (not recommended, slows down execution speed terribly on some
> systems), I am not aware of similar mechanisms for the string classes.
>
> Salut,
>       Bastien
>
> PS: This is _definitively_ something for the FAQ.

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

[Philippe E. <ph...@wa...>]

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.

feel free to change the wording if there is any problem.

btw I posted syscall 253 implementation a week ago. Any comment ?

http://sourceforge.net/mailarchive/forum.php?thread_id=1982441&forum_id=12302

regards,
Phil

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. --

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.