public inbox for libstdc++-cvs@sourceware.org
help / color / mirror / Atom feed
* [gcc/devel/c++-modules] libstdc++: Update/streamline Valgrind references
@ 2020-06-11 13:01 Nathan Sidwell
0 siblings, 0 replies; only message in thread
From: Nathan Sidwell @ 2020-06-11 13:01 UTC (permalink / raw)
To: gcc-cvs, libstdc++-cvs
https://gcc.gnu.org/g:e41b988cc5af34e9c1a3d37b717fbfcc52d7ff90
commit e41b988cc5af34e9c1a3d37b717fbfcc52d7ff90
Author: Gerald Pfeifer <gerald@pfeifer.com>
Date: Mon Jun 1 17:03:51 2020 +0200
libstdc++: Update/streamline Valgrind references
* doc/xml/faq.xml: Adjust Valgrind reference and remove another.
* doc/html/faq.html: Regenerate.
Diff:
---
libstdc++-v3/doc/html/faq.html | 4 ++--
libstdc++-v3/doc/xml/faq.xml | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libstdc++-v3/doc/html/faq.html b/libstdc++-v3/doc/html/faq.html
index 18407225d7a..967e5f5f348 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>
diff --git a/libstdc++-v3/doc/xml/faq.xml b/libstdc++-v3/doc/xml/faq.xml
index cf8684e1cea..e419d3c22a0 100644
--- a/libstdc++-v3/doc/xml/faq.xml
+++ b/libstdc++-v3/doc/xml/faq.xml
@@ -993,7 +993,7 @@
of a few dozen kilobytes on startup. This pool is used to ensure it's
possible to throw exceptions (such as <classname>bad_alloc</classname>)
even when <code>malloc</code> is unable to allocate any more memory.
- With some versions of <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://valgrind.org/"><command>valgrind</command></link>
+ With some versions of <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://valgrind.org"><command>valgrind</command></link>
this pool will be shown as "still reachable" when the process exits, e.g.
<code>still reachable: 72,704 bytes in 1 blocks</code>.
This memory is not a leak, because it's still in use by libstdc++,
@@ -1004,7 +1004,7 @@
<para>
In the past, a few people reported that the standard containers appear
to leak memory when tested with memory checkers such as
- <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://valgrind.org/"><command>valgrind</command></link>.
+ <command>valgrind</command>.
Under some (non-default) configurations the library's allocators keep
free memory in a
pool for later reuse, rather than deallocating it with <code>delete</code>
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2020-06-11 13:01 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-11 13:01 [gcc/devel/c++-modules] libstdc++: Update/streamline Valgrind references Nathan Sidwell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).