public inbox for libstdc++-cvs@sourceware.org help / color / mirror / Atom feed
From: Giuliano Belinassi <giulianob@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org, libstdc++-cvs@gcc.gnu.org Subject: [gcc/devel/autopar_devel] libstdc++: Update/streamline Valgrind references Date: Sat, 22 Aug 2020 21:47:11 +0000 (GMT) [thread overview] Message-ID: <20200822214711.3DC53388C015@sourceware.org> (raw) https://gcc.gnu.org/g:1ba238b57e6f77207eeb00055b2347bf02dc56a2 commit 1ba238b57e6f77207eeb00055b2347bf02dc56a2 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>
reply other threads:[~2020-08-22 21:47 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200822214711.3DC53388C015@sourceware.org \ --to=giulianob@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ --cc=libstdc++-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).