From: Julian Seward <jseward@acm.org>
Date: Sat, 26 Apr 2003 22:23:35 +0000 (+0000)
Subject: Add FAQ entry re apparent space leaks in the STL.
X-Git-Tag: svn/VALGRIND_2_0_0~194
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=a01d8e81dfafa8f66687b3de397ea999f09dcf96;p=thirdparty%2Fvalgrind.git

Add FAQ entry re apparent space leaks in the STL.

MERGE TO STABLE


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1565
---

diff --git a/FAQ.txt b/FAQ.txt
index 674fb281a0..700085a740 100644
--- a/FAQ.txt
+++ b/FAQ.txt
@@ -187,6 +187,8 @@ A9. Try the following.  It is an experiment, but it might work.
          return -1;
        }
 
+    (Note: this fix is already in version 1.9.6 and later)
+
 -----------------------------------------------------------------
 
 Q10. I upgraded to Red Hat 9 and threaded programs now act
@@ -306,4 +308,49 @@ A13.  This is a total swamp.  Nevertheless there is a way out.
 
 -----------------------------------------------------------------
 
+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 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 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 by 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 
+            ("now" == 26 Apr 03)
+
+         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.
+
+-----------------------------------------------------------------
+
 (this is the end of the FAQ.)