mirrors/gcc
1
0
Fork 0
mirror of https://gcc.gnu.org/git/gcc.git synced 2024-11-24 03:14:08 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

libstdc++: Update/streamline Valgrind references

Browse Source 
* doc/xml/faq.xml: Adjust Valgrind reference and remove another.
	* doc/html/faq.html: Regenerate.
This commit is contained in:
Gerald Pfeifer 2020-06-01 17:03:51 +02:00
parent ff7da2b5d6
commit e41b988cc5
2 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
libstdc++-v3/doc/html/faq.html
View File

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

4
libstdc++-v3/doc/xml/faq.xml
View File

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