diff options
author | Gerald Pfeifer <gerald@pfeifer.com> | 2020-06-01 17:03:51 +0200 |
---|---|---|
committer | Gerald Pfeifer <gerald@pfeifer.com> | 2020-06-01 17:04:22 +0200 |
commit | e41b988cc5af34e9c1a3d37b717fbfcc52d7ff90 (patch) | |
tree | 3330771d4155bb0a944279ad55d72cacd8a8ed11 /libstdc++-v3/doc/html | |
parent | ff7da2b5d621d0aaf4a467344d0621eefd4aa78f (diff) | |
download | gcc-e41b988cc5af34e9c1a3d37b717fbfcc52d7ff90.zip gcc-e41b988cc5af34e9c1a3d37b717fbfcc52d7ff90.tar.gz gcc-e41b988cc5af34e9c1a3d37b717fbfcc52d7ff90.tar.bz2 |
libstdc++: Update/streamline Valgrind references
* doc/xml/faq.xml: Adjust Valgrind reference and remove another.
* doc/html/faq.html: Regenerate.
Diffstat (limited to 'libstdc++-v3/doc/html')
-rw-r--r-- | libstdc++-v3/doc/html/faq.html | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/libstdc++-v3/doc/html/faq.html b/libstdc++-v3/doc/html/faq.html index 1840722..967e5f5 100644 --- a/libstdc++-v3/doc/html/faq.html +++ b/libstdc++-v3/doc/html/faq.html @@ -700,7 +700,7 @@ of a few dozen kilobytes on startup. This pool is used to ensure it's possible to throw exceptions (such as <code class="classname">bad_alloc</code>) even when <code class="code">malloc</code> is unable to allocate any more memory. - With some versions of <a class="link" href="http://valgrind.org/" target="_top"><span class="command"><strong>valgrind</strong></span></a> + With some versions of <a class="link" href="https://valgrind.org" target="_top"><span class="command"><strong>valgrind</strong></span></a> this pool will be shown as "still reachable" when the process exits, e.g. <code class="code">still reachable: 72,704 bytes in 1 blocks</code>. This memory is not a leak, because it's still in use by libstdc++, @@ -710,7 +710,7 @@ </p><p> In the past, a few people reported that the standard containers appear to leak memory when tested with memory checkers such as - <a class="link" href="http://valgrind.org/" target="_top"><span class="command"><strong>valgrind</strong></span></a>. + <span class="command"><strong>valgrind</strong></span>. Under some (non-default) configurations the library's allocators keep free memory in a pool for later reuse, rather than deallocating it with <code class="code">delete</code> |