From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id B693939A2487 for ; Fri, 6 Aug 2021 14:09:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B693939A2487 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: xT8Ez3xnwUmy3pQLEFibjCaPCYbYHmwaSDLFHs80t3I2gNNClotl5IEiuT4lgFnf4bV7f1xxgm FUAS+whH66T7aM2boP4uoJ9uAltc8KW+04rcZ7w1aFNIdNLKaCTkpZ+eg/+8z4DGPb3tuLwTLw 9EFYhU3iilK1h2iRUubS/ynwlline6Fniy0AkCN7i4P/DUqFB5GxjgIeXxi0VO/wSS3vW3qoS2 IlsZqRqbxiK/+DySB0LtxC1qP/pvWougXnppCjHmLSVuLfVh1B+ahDp5N53UIGGx77Ok/ULFX3 yrH1TJGQIOraeeu48ZBZnBFt X-IronPort-AV: E=Sophos;i="5.84,300,1620720000"; d="scan'208";a="64365569" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 06 Aug 2021 06:09:48 -0800 IronPort-SDR: epAPs8ks3uLWOJLSVOYm2Ez3r7a+NheNYREMfJqcZ9Ogc9j+5eJqAsm7uYewNSc224P8nvtLNN nW701Dr6XXpk6wAB5st0tvV+fQpCdNFb7oSeuAoXVN9hJEoEmePOBuwQ3Ct2vUonNhjlyQvwbj Gs9xfQDCsi/O5nVjE0qvqkLM4fVC66jcF+aRsVVp7t5gDkU6CZpfunmBXis6nfC0elMYV3Aep6 KNXCUQ8qtYVGifwo7tUD39VRIjtxHU4RsfZefGmmSrt0gzsEeVZ7WQh8mk5g3qFSJtk6tU2EsW Ers= From: Thomas Schwinge To: , Richard Biener , Martin Sebor Subject: Valgrind '--show-leak-kinds=all' In-Reply-To: References: <3d205f84-c076-0388-ad60-24cd94d61696@gmail.com> <23a920e2-a6e2-f7db-8e75-ff6224f732d2@gmail.com> User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Fri, 6 Aug 2021 16:09:37 +0200 Message-ID: <87im0ihdge.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: , X-List-Received-Date: Fri, 06 Aug 2021 14:10:01 -0000 Hi! I'm working on plugging a memory leak in an entirely different compartment of GCC, but also ran into this issue: On 2021-02-12T08:35:52+0100, Richard Biener via Gcc-patches wrote: > On Thu, Feb 11, 2021 at 7:35 PM Martin Sebor wrote: >> On 2/11/21 12:59 AM, Richard Biener wrote: >> > On Wed, Feb 10, 2021 at 6:16 PM Martin Sebor wrote: >> >> [...] Valgrind shows more leaks in this code that >> >> I'm not sure what to do about: >> >> >> >> 1) A tree built by build_type_attribute_qual_variant() called from >> >> attr_access::array_as_string() to build a temporary type only >> >> for the purposes of formatting it. >> >> >> >> 2) A tree (an attribute list) built by tree_cons() called from >> >> build_attr_access_from_parms() that's used only for the duration >> >> of the caller. >> >> >> >> Do these temporary trees need to be released somehow or are the leaks >> >> expected? >> > >> > You should configure GCC with --enable-valgrind-annotations to make >> > it aware of our GC. >> >> I did configure with that option: >> >> $ /src/gcc/master/configure --enable-checking=3Dyes >> --enable-languages=3Dall,jit,lto --enable-host-shared >> --enable-valgrind-annotations >> $ /build/gcc-master/gcc/xgcc -B /build/gcc-master/gcc -S -Wall >> /src/gcc/master/gcc/testsuite/gcc.dg/Wvla-parameter.c -wrapper >> valgrind,--leak-check=3Dfull,--show-leak-kinds=3Dall,--track-origins=3Dy= es,--log-file=3Dvalgrind-out.txt >> >> Do you not see the same leaks? I do; also stuff like: 56 bytes in 1 blocks are still reachable in loss record 152 of 875 at 0x483DD99: calloc (vg_replace_malloc.c:762) by 0x1753240: xcalloc (xmalloc.c:162) by 0x669C83: ggc_internal_alloc(unsigned long, void (*)(void*), unsi= gned long, unsigned long) (ggc-page.c:918) by 0x89E07D: ggc_internal_cleared_alloc(unsigned long, void (*)(void= *), unsigned long, unsigned long) (ggc-common.c:117) by 0xF65D0D: make_node(tree_code) (ggc.h:143) by 0xF6632B: build_decl(unsigned int, tree_code, tree_node*, tree_no= de*) (tree.c:5264) by 0xA28ADC: build_builtin_function(unsigned int, char const*, tree_= node*, int, built_in_class, char const*, tree_node*) (langhooks.c:681) by 0xA29FDD: add_builtin_function(char const*, tree_node*, int, buil= t_in_class, char const*, tree_node*) (langhooks.c:716) by 0x622BFB: def_builtin_1(built_in_function, char const*, built_in_= class, tree_node*, tree_node*, bool, bool, bool, tree_node*, bool) [clone .= constprop.25] (lto-lang.c:650) by 0x640709: lto_define_builtins(tree_node*, tree_node*) (omp-builti= ns.def:46) by 0x641EE3: lto_init() (lto-lang.c:1339) by 0x61E26A: toplev::main(int, char**) (toplev.c:1921) ... and many, many more. > Err, well. --show-leak-kinds=3Dall is probably the cause. Before finding this email, I too had convinced myself that everying that came by 'ggc_*' I may ignore, because: > We > definitely do not force-release > all reachable GC allocated memory at program end. ... of this: these blocks simply had not been GCed at program end. It's however a bit tedious to filter, in my case, 11864 lines of Valgrind output. > Not sure if > valgrind annotations can > make that obvious to valgrind. Or, if that's not feasible (I don't know much about Valgrind...), then instead would it help to force a final GC at program end if we're running in "valgrind mode"? If that's a plausible thing to do, would guarding that by GCC having been configured with '--enable-valgrind-annotations' be OK, or do we need a '--param', or something else? > I'm just using --leak-check=3Dfull and > thus look for > unreleased and no longer reachable memory. ACK, in my case, that only shows seven errors (not related to my stuff). Gr=C3=BC=C3=9Fe Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955