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.  
  First   of   all:   relax,   it's   probably   not   a   bug,   but   a   feature.   Many   implementations   of   the   C++   standard   libraries   use   their   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   cause   Valgrind   to   report   this   memory   as   still   reachable.   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   gcc   3.2.2   and   later,   you   should   export   the   environment   variable   GLIBCPP_FORCE_NEW   before   running   your   program.

With   gcc   3.4   and   later,   that   variable   has   changed   name   to   GLIBCXX_FORCE_NEW.

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   by   reading   http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#3   if   you   absolutely   want   to   do   that.   But   beware:

there   are   currently   changes   underway   for   gcc   which   are   not   totally   reflected   in   the   docs   right   now   ("now"   ==   26   Apr   03)

allocators   belong   to   the   more   messy   parts   of   the   STL   and   people   went   to   great   lengths   to   make   it   portable   across   platforms.   Chances   are   good   that   your   solution   will   work   on   your   platform,   but   not   on   others.
 
为什么定义了GLIBCXX_FORCE_NEW这个环境变量后使用stl还是会存在内存泄露？那位大虾也碰到过这个问题并解决了的还请多多指教。

首先帮你排了一下版。关于Valgrind的'still reachable'，可以参考我回答的另一个问题，也许不是问题：
http://topic.csdn.net/u/20080104/10/7ed09e99-a2c0-489b-8fd8-9c222b4d11eb.html

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.
 First of all: relax, it's probably not a bug, but a feature. Many implementations of the C++ standard libraries use their 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 cause Valgrind to report this memory as still reachable. 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 gcc 3.2.2 and later, you should export the environment variable GLIBCPP_FORCE_NEW before running your program.

 With gcc 3.4 and later, that variable has changed name to GLIBCXX_FORCE_NEW.

 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 by reading http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#3 if you absolutely want to do that. But beware:

 there are currently changes underway for gcc which are not totally reflected in the docs right now ("now" == 26 Apr 03)

 allocators belong to the more messy parts of the STL and people went to great lengths to make it portable across platforms. Chances are good that your solution will work on your platform, but not on others.

好像是与realloc有关系
实在想不起来了
那篇文章找不到了