From patchwork Mon Jun 1 15:06:31 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gerald Pfeifer X-Patchwork-Id: 1301789 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=pfeifer.com Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 49bJRg4ZCQz9sSy for ; Tue, 2 Jun 2020 01:06:54 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9C9BC3851C09; Mon, 1 Jun 2020 15:06:51 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from hamza.pair.com (hamza.pair.com [209.68.5.143]) by sourceware.org (Postfix) with ESMTPS id 8503E3851C01; Mon, 1 Jun 2020 15:06:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8503E3851C01 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=pfeifer.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gerald@pfeifer.com Received: from hamza.pair.com (localhost [127.0.0.1]) by hamza.pair.com (Postfix) with ESMTP id 35A0333E10; Mon, 1 Jun 2020 11:06:49 -0400 (EDT) Received: from [192.168.1.5] (unknown [77.118.218.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hamza.pair.com (Postfix) with ESMTPSA id 8768933E0C; Mon, 1 Jun 2020 11:06:48 -0400 (EDT) Date: Mon, 1 Jun 2020 17:06:31 +0200 (CEST) From: Gerald Pfeifer To: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: [committed] libstdc++: Update/streamline Valgrind references MIME-Version: 1.0 Message-Id: <20200601150649.35A0333E10@hamza.pair.com> X-Spam-Status: No, score=-11.2 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces@gcc.gnu.org Sender: "Gcc-patches" Like many sites over the last year(s) valgrind.org has now moved to https. While there, replace the second of two links in the same vicinity by a purely textual reference -- easier to maintain, and in particular also better from a user experience perspective. Gerald * doc/xml/faq.xml: Adjust Valgrind reference and remove another. * doc/html/faq.html: Regenerate. --- 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 bad_alloc) even when malloc is unable to allocate any more memory. - With some versions of valgrind + 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++, @@ -710,7 +710,7 @@

In the past, a few people reported that the standard containers appear to leak memory when tested with memory checkers such as - valgrind. + valgrind. Under some (non-default) configurations the library's allocators keep free memory in a pool for later reuse, rather than deallocating it with delete 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 bad_alloc) even when malloc is unable to allocate any more memory. - With some versions of valgrind + 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++, @@ -1004,7 +1004,7 @@ In the past, a few people reported that the standard containers appear to leak memory when tested with memory checkers such as - valgrind. + valgrind. Under some (non-default) configurations the library's allocators keep free memory in a pool for later reuse, rather than deallocating it with delete