ChapterÂ 3.Â Using

- A few people have reported that the standard containers appear + âMemory leaksâ in libstdc++ +

+ 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/html/index.html b/libstdc++-v3/doc/html/index.html index 7a8c652cabe..25447dbcefe 100644 --- a/libstdc++-v3/doc/html/index.html +++ b/libstdc++-v3/doc/html/index.html @@ -23,7 +23,7 @@

`3.2`

Symbol versioning introduced for shared library.

Removal of include <backward/strstream.h>.

Allocator changes. Change __malloc_alloc to malloc_allocator and __new_alloc to new_allocator.

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.

Error handling in iostreams cleaned up, made consistent.

`3.3`

diff --git a/libstdc++-v3/doc/html/manual/backwards.html b/libstdc++-v3/doc/html/manual/backwards.html index 2758f34d858..5116ae94bcd 100644 --- a/libstdc++-v3/doc/html/manual/backwards.html +++ b/libstdc++-v3/doc/html/manual/backwards.html @@ -484,8 +484,9 @@ No stream::attach(int fd) stream-constructor.

An extension is available that implements this. - <ext/stdio_filebuf.h> contains a derived class called - __gnu_cxx::stdio_filebuf. + <ext/stdio_filebuf.h> + contains a derived class called + __gnu_cxx::stdio_filebuf. This class can be constructed from a C FILE* or a file descriptor, and provides the fd() function.

diff --git a/libstdc++-v3/doc/html/manual/debug.html b/libstdc++-v3/doc/html/manual/debug.html index 5e37b0e2476..bce4242cdde 100644 --- a/libstdc++-v3/doc/html/manual/debug.html +++ b/libstdc++-v3/doc/html/manual/debug.html @@ -53,40 +53,28 @@ This quick and dirty approach is often sufficient for quick debugging tasks, when you cannot or don't want to recompile your application to use the debug mode.

`Memory Leak Hunting`

- There are various third party memory tracing and debug utilities + On many targets GCC supports AddressSanitizer, a fast memory error detector, + which is enabled by the -fsanitize=address option. +

+ 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.

@@ -121,7 +109,29 @@
   up the runtime environment, library, and test file, might be:
 
    valgrind -v --num-callers=20 --leak-check=yes --leak-resolution=high --show-reachable=yes a.out
-

`Data Race Hunting`

+

`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`

All synchronization primitives used in the library internals need to be understood by race detectors so that they do not produce false reports.

diff --git a/libstdc++-v3/doc/html/manual/ext_concurrency_impl.html b/libstdc++-v3/doc/html/manual/ext_concurrency_impl.html index 5fecd4afec0..509c620087b 100644 --- a/libstdc++-v3/doc/html/manual/ext_concurrency_impl.html +++ b/libstdc++-v3/doc/html/manual/ext_concurrency_impl.html @@ -44,7 +44,7 @@ a POSIX-like interface. the current host. In libstdc++ implementation files, <bits/gthr.h> is used to select the proper gthreads file.

Within libstdc++ sources, all calls to underlying thread functionality -use this layer. More detail as to the specific interface can be found in the source documentation. +use this layer. More detail as to the specific interface can be found in the source documentation.

By design, the gthread layer is interoperable with the types, functions, and usage found in the usual <pthread.h> file, including pthread_t, pthread_once_t, pthread_create, diff --git a/libstdc++-v3/doc/html/manual/ext_io.html b/libstdc++-v3/doc/html/manual/ext_io.html index 7e24bedef7f..2959d5d554f 100644 --- a/libstdc++-v3/doc/html/manual/ext_io.html +++ b/libstdc++-v3/doc/html/manual/ext_io.html @@ -34,11 +34,13 @@ library cannot track what you do on your own with a file descriptor, so if you perform any I/O directly, don't expect the library to be aware of it. -

Beginning with 3.1, the extra filebuf constructor and +

Beginning with 3.1, the extra + basic_filebuf constructor and the fd() function were removed from the standard - filebuf. Instead, <ext/stdio_filebuf.h> contains - a derived class called - __gnu_cxx::stdio_filebuf. + filebuf. Instead, + <ext/stdio_filebuf.h> + contains a derived class template called + __gnu_cxx::stdio_filebuf. This class can be constructed from a C FILE* or a file descriptor, and provides the fd() function.

template<typename T> diff --git a/libstdc++-v3/doc/html/manual/using.html b/libstdc++-v3/doc/html/manual/using.html index 332725b2aaa..355790d28de 100644 --- a/libstdc++-v3/doc/html/manual/using.html +++ b/libstdc++-v3/doc/html/manual/using.html @@ -2,7 +2,7 @@ ChapterÂ 3.Â Using

ChapterÂ 3.Â Using
PrevÂ	PartÂ I.Â Introduction -	Â Next

ChapterÂ 3.Â Using

Command Options

+Â Next

ChapterÂ 3.Â Using

Command Options

The set of features available in the GNU C++ library is shaped by several GCC Command Options. Options that impact libstdc++ are @@ -26,4 +26,7 @@ -lstdc++fsLinking to libstdc++fs is required for use of the Filesystem library extensions in <experimental/filesystem>. - -fopenmpFor parallel mode.

PrevÂ	Up	Â Next
MakeÂ	Home	Â Headers

\ No newline at end of file + -fopenmpFor parallel mode.-ltbbLinking to tbb (Thread Building Blocks) is required for use of the + Parallel Standard Algorithms and execution policies in + <execution>. +

PrevÂ	Up	Â Next
MakeÂ	Home	Â Headers

\ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml index bb82e34bba7..73403ef6ba0 100644 --- a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml +++ b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml @@ -633,17 +633,18 @@ Feature-testing recommendations for C++. - + The Parallelism TS Should be Standardized P0024R2 - No + 9.1 __has_include(<execution>) , __cpp_lib_execution >= 201603 , __cpp_lib_parallel_algorithm >= 201603 + (requires linking with -ltbb, see Note 3) @@ -689,7 +690,7 @@ Feature-testing recommendations for C++. 7.1 __cpp_lib_math_special_functions >= 201603 - (see Note 3) + (see Note 4) @@ -841,7 +842,13 @@ Note 2: This feature is supported in older releases but the -Note 3: The mathematical special functions are enabled in C++17 mode from +Note 3: The Parallel Algorithms have an external dependency on Intel TBB 2018 +or later. If the <execution> +header is included then -ltbb must be used to link to TBB. + + + +Note 4: The mathematical special functions are enabled in C++17 mode from GCC 7.1 onwards. For GCC 6.x or for C++11/C++14 define __STDCPP_WANT_MATH_SPEC_FUNCS__ to a non-zero value and test for __STDCPP_MATH_SPEC_FUNCS__ >= 201003L. -- 2.30.2

PrevÂ	Up	Â Next
ChapterÂ 27.Â IteratorsÂ	Home	Â ChapterÂ 29.Â Demangling

PrevÂ	Up	Â Next
The GNU C++ Library ManualÂ	Home	Â ChapterÂ 1.Â Status

Note

3.2

3.3

Memory Leak Hunting

Data Race Hunting

Non-memory leaks in Pool and MT allocators

Data Race Hunting

PartÂ I.Â Introduction -

ChapterÂ 3.Â Using

Command Options

ChapterÂ 3.Â Using

Command Options

`3.2`

`3.3`

`Memory Leak Hunting`

`Data Race Hunting`

`Non-memory leaks in Pool and MT allocators`

`Data Race Hunting`