From: Jonathan Wakely Date: Wed, 10 Apr 2019 19:24:04 +0000 (+0100) Subject: Update documentation regarding bogus memory leaks in libstdc++ X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=51d3c11a7c79294599c1e9088c80f7417566a75e;p=gcc.git Update documentation regarding bogus memory leaks in libstdc++ * doc/xml/faq.xml: Add information about emergency EH pool. * doc/xml/manual/debug.xml: Update list of memory debugging tools. Move outdated information on mt_allocator to a separate section. * doc/xml/manual/evolution.xml: Clarify that GLIBCXX_FORCE_NEW doesn't affect the default allocator. From-SVN: r270264 --- diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index 99986074413..6148f5ce944 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,5 +1,11 @@ 2019-04-10 Jonathan Wakely + * doc/xml/faq.xml: Add information about emergency EH pool. + * doc/xml/manual/debug.xml: Update list of memory debugging tools. + Move outdated information on mt_allocator to a separate section. + * doc/xml/manual/evolution.xml: Clarify that GLIBCXX_FORCE_NEW + doesn't affect the default allocator. + * testsuite/lib/libstdc++.exp (check_v3_target_parallel_mode): Fix typo. diff --git a/libstdc++-v3/doc/xml/faq.xml b/libstdc++-v3/doc/xml/faq.xml index edc07f16acb..b4bf333e26a 100644 --- a/libstdc++-v3/doc/xml/faq.xml +++ b/libstdc++-v3/doc/xml/faq.xml @@ -1001,21 +1001,31 @@ - Memory leaks in containers + Memory leaks in libstdc++ - - This answer is old and probably no longer be relevant. - - A few people have reported that the standard containers appear + Since GCC 5.1.0, libstdc++ automatically allocates a pool + of a few dozen kilobytes on startup. This pool is used to ensure it's + possible to throw exceptions (such as bad_alloc) + even when malloc is unable to allocate any more memory. + With some versions of valgrind + this pool will be shown as "still reachable" when the process exits, e.g. + still reachable: 72,704 bytes in 1 blocks. + This memory is not a leak, because it's still in use by libstdc++, + and the memory will be returned to the OS when the process exits. + Later versions of valgrind know how to free this + pool as the process exits, and so won't show any "still reachable" memory. + + + In the past, a few people reported that the standard containers appear to leak memory when tested with memory checkers such as valgrind. Under some (non-default) configurations the library's allocators keep free memory in a - pool for later reuse, rather than returning it to the OS. Although - this memory is always reachable by the library and is never + pool for later reuse, rather than deallocating it with delete + Although this memory is always reachable by the library and is never lost, memory debugging tools can report it as a leak. If you want to test the library for memory leaks please read Tips for memory leak hunting diff --git a/libstdc++-v3/doc/xml/manual/debug.xml b/libstdc++-v3/doc/xml/manual/debug.xml index 37e330d3ed2..091e0b6914c 100644 --- a/libstdc++-v3/doc/xml/manual/debug.xml +++ b/libstdc++-v3/doc/xml/manual/debug.xml @@ -94,50 +94,35 @@
Memory Leak Hunting + + On many targets GCC supports AddressSanitizer, a fast memory error detector, + which is enabled by the option. + - There are various third party memory tracing and debug utilities + There are also various third party memory tracing and debug utilities that can be used to provide detailed memory allocation information about C++ code. An exhaustive list of tools is not going to be attempted, but includes mtrace, valgrind, - mudflap, and the non-free commercial product - purify. In addition, libcwd has a - replacement for the global new and delete operators that can track - memory allocation and deallocation and provide useful memory - statistics. - - - - Regardless of the memory debugging tool being used, there is one - thing of great importance to keep in mind when debugging C++ code - that uses new and delete: there are - different kinds of allocation schemes that can be used by - std::allocator. For implementation details, see the mt allocator documentation and - look specifically for GLIBCXX_FORCE_NEW. - - - - In a nutshell, the optional mt_allocator - is a high-performance pool allocator, and can - give the mistaken impression that in a suspect executable, memory is - being leaked, when in reality the memory "leak" is a pool being used - by the library's allocator and is reclaimed after program - termination. + mudflap (no longer supported since GCC 4.9.0), ElectricFence, + and the non-free commercial product purify. + In addition, libcwd, jemalloc and TCMalloc have replacements + for the global new and delete operators + that can track memory allocation and deallocation and provide useful + memory statistics. For valgrind, there are some specific items to keep in mind. First of all, use a version of valgrind that will work with current GNU C++ tools: the first that can do this is valgrind 1.0.4, but later - versions should work at least as well. Second of all, use a - completely unoptimized build to avoid confusing valgrind. Third, use - GLIBCXX_FORCE_NEW to keep extraneous pool allocation noise from - cluttering debug information. + versions should work better. Second, using an unoptimized build + might avoid confusing valgrind. - Fourth, it may be necessary to force deallocation in other libraries - as well, namely the "C" library. On linux, this can be accomplished + Third, it may be necessary to force deallocation in other libraries + as well, namely the "C" library. On GNU/Linux, this can be accomplished with the appropriate use of the __cxa_atexit or atexit functions. @@ -157,7 +142,6 @@ } - or, using __cxa_atexit: @@ -184,6 +168,39 @@ valgrind -v --num-callers=20 --leak-check=yes --leak-resolution=high --show-reachable=yes a.out +
+Non-memory leaks in Pool and MT allocators + + + There are different kinds of allocation schemes that can be used by + std::allocator. Prior to GCC 3.4.0 the default was to use + a pooling allocator, pool_allocator, + which is still available as the optional + __pool_alloc extension. + Another optional extension, __mt_alloc, + is a high-performance pool allocator. + + + + In a suspect executable these pooling allocators can give + the mistaken impression that memory is being leaked, + when in reality the memory "leak" is a pool being used + by the library's allocator and is reclaimed after program + termination. + + + + If you're using memory debugging tools on a program that uses + one of these pooling allocators, you can set the environment variable + GLIBCXX_FORCE_NEW to keep extraneous pool allocation + noise from cluttering debug information. + For more details, see the + mt allocator + documentation and look specifically for GLIBCXX_FORCE_NEW. + + +
+
Data Race Hunting diff --git a/libstdc++-v3/doc/xml/manual/evolution.xml b/libstdc++-v3/doc/xml/manual/evolution.xml index e24418fefc0..c7efb8f0f8a 100644 --- a/libstdc++-v3/doc/xml/manual/evolution.xml +++ b/libstdc++-v3/doc/xml/manual/evolution.xml @@ -79,11 +79,12 @@ Removal of <ext/tree>, moved to For GCC releases from 2.95 through the 3.1 series, defining __USE_MALLOC on the gcc command line would change the - default allocation strategy to instead use malloc and - free. For the 3.2 and 3.3 release series the same + default allocation strategy to instead use malloc and + free. For the 3.2 and 3.3 release series the same functionality was spelled _GLIBCXX_FORCE_NEW. From - GCC 3.4 onwards the functionality is enabled by setting - GLIBCXX_FORCE_NEW in the environment, see + GCC 3.4 onwards the default allocator uses new anyway, + but for the optional pooling allocators the functionality is enabled by + setting GLIBCXX_FORCE_NEW in the environment, see the mt allocator chapter for details.