From: Paul Floyd Date: Mon, 1 Jun 2026 05:42:01 +0000 (+0200) Subject: Bug 520861 - Update FAQ for C++ standard library X-Git-Url: http://git.ipfire.org/gitweb/index.cgi?a=commitdiff_plain;h=65cd804dc0914eb1c8a69f7703efb60de7cd8502;p=thirdparty%2Fvalgrind.git Bug 520861 - Update FAQ for C++ standard library --- diff --git a/NEWS b/NEWS index e7da5dc0d..dd86e0f67 100644 --- a/NEWS +++ b/NEWS @@ -38,6 +38,7 @@ are not entered into bugzilla tend to get forgotten about or ignored. on error, leading to a ~60s wallclock time delay on every call 520482 Advertise POPCNT on x86 via CPUID 520856 unhandled instruction bytes: 0x2E 0xFF 0x14 0x85 +520861 Update FAQ for C++ standard library To see details of a given bug, visit https://bugs.kde.org/show_bug.cgi?id=XXXXXX diff --git a/docs/xml/FAQ.xml b/docs/xml/FAQ.xml index 2d070f01b..79907e0c6 100644 --- a/docs/xml/FAQ.xml +++ b/docs/xml/FAQ.xml @@ -225,60 +225,6 @@ collect2: ld returned 1 exit status Valgrind behaves unexpectedly - - - 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 was - 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++/faq/index.html#4_4_leak - if you absolutely want to do that. But beware: - allocators belong to the more messy parts of the STL and - people went to great lengths to make the STL portable across - platforms. Chances are good that your solution will work on your - platform, but not on others. - - - - The stack traces given by Memcheck (or another tool) aren't @@ -575,6 +521,56 @@ int main(void) + + + My program uses the GNU C++ standard library container and string classes. + Valgrind reports 'still reachable' memory leaks involving these classes at the exit + of the program, but there should be none. + + + If Valgrind reports a leak in C++ code using a GCC version dating from 2005 or later, + the most likely cause is a bug in your code, such as a missing deallocation or + a cyclic reference. + If you are using an old version of GCC (version 3.4 from 2004 or earlier) + or if you are using the optional __gnu_cxx::pool_alloc or + __gnu_cxx::__mt_alloc (both of which are considered obsolete), then this + may be a feature of the standard library implementation and not a bug in your + code. + These old C++ libraries and specialised allocators use their own + memory pools. 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 causes + Valgrind to report this memory as still reachable. + + Using GCC, you can force the standard library to use new and delete + directly, thus globally disabling memory caching. + + + + With GCC 3.4 and later you should export the environment variable + GLIBCXX_FORCE_NEW before running your program. + + + With GCC 3.2.2 up to GCC 3.4, the name of the environment + variable was GLIBCPP_FORCE_NEW. + + + With GCC 2.91, 2.95, 3.0 and 3.1, compile all source using + the standard library with -D__USE_MALLOC. + + + + If you replace the default std::allocator with your own allocator + or if you use a std::pmr::polymorphic_allocator, then you may have + similar issues. Dealing with these issues is beyond the scope of this document. + To read more about C++ allocators, see the cppreference pages on allocator + or polymorphic_allocator. + To read more about how to teach Valgrind to understand memory pools, see + for details. This guide + also shows how to instrument memory pools. + + +