Add FAQ entry re apparent space leaks in the STL.
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1565 a5019735-40e9-0310-863c-91ae7b9d1cf9
diff --git a/FAQ.txt b/FAQ.txt
index 674fb28..700085a 100644
--- a/FAQ.txt
+++ b/FAQ.txt
@@ -187,6 +187,8 @@
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 @@
-----------------------------------------------------------------
+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.)