From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 92EFC388E81F for ; Tue, 17 Aug 2021 13:00:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 92EFC388E81F 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: 0aDSA8IO8Fp+K3u5JEmwtv6bez/Ehv1gsaXaRVWkR0qscfVeTYf/ot0CXy7/DyzNNHCZlxr8/7 ei6s1Z0qp37SaDMggIAlnvve6C+cD0Eff+tOC0v9kHY2yjMlOoK6t1oDRGynE/Tt7k3ZcCVRKc 29t36unS2JuX4CLo/Cg02IwgFFUzbgr1RxtCMVphS2q8pPnFWA1UBnE9TvM38HwvhIYV1c9mnJ +9mdfg/79Kx3+N7mP4esL/NlV9WexK8MBvw7snhtjA0zstJ1Mv2THR/1Opq3TmmsNGk0/UA0tQ QalVXNzsEvWmkwPfnI1/SIet X-IronPort-AV: E=Sophos;i="5.84,328,1620720000"; d="scan'208";a="67274321" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa1.mentor.iphmx.com with ESMTP; 17 Aug 2021 05:00:45 -0800 IronPort-SDR: 9KBqYtShDPwjGqW/pjURUWQ13S2vBipdOuZsKuulRSVHeUlyUcm6LgxW2NwetziLs6TVfgsTwg 9ftlLO/jPW2jHM2pQruBiAaJ5Tnrk1YD+Q4c3Jh4SBpTIrkQjAmtFdMDyRHyDUgW+p7Nhfm2o9 gy0v8LqrwX5pmZLlMMgjjY2Mw9uo0B+9QG6rVshFxOFW7o/ByJslajEpfrx3MHYbo/uEUJpnQc aeY0MxQ4F01mMJfrJgvor7XJvga0Kk4KFZ34XYI4vG2qpIQ5svi3Hhdg5jcWjX3EgEbYw+6D/N GFs= From: Thomas Schwinge To: Richard Biener , , Martin Sebor Subject: Re: Valgrind '--show-leak-kinds=all' In-Reply-To: <17082A31-CA8B-4FF0-B36B-A6D754B1BCB0@gmail.com> References: <3d205f84-c076-0388-ad60-24cd94d61696@gmail.com> <23a920e2-a6e2-f7db-8e75-ff6224f732d2@gmail.com> <87im0ihdge.fsf@euler.schwinge.homeip.net> <17082A31-CA8B-4FF0-B36B-A6D754B1BCB0@gmail.com> User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Tue, 17 Aug 2021 15:00:37 +0200 Message-ID: <87y290ns3u.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-07.mgc.mentorg.com (139.181.222.7) 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, KAM_SHORT, 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: Tue, 17 Aug 2021 13:00:56 -0000 Hi! On 2021-08-06T17:10:36+0200, Richard Biener wr= ote: > On August 6, 2021 4:09:37 PM GMT+02:00, Thomas Schwinge wrote: >>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 wrot= e: >>>> >> [...] 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 durati= on >>>> >> of the caller. >>>> >> >>>> >> Do these temporary trees need to be released somehow or are the lea= ks >>>> >> 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= =3Dyes,--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*), un= signed long, unsigned long) (ggc-page.c:918) >> by 0x89E07D: ggc_internal_cleared_alloc(unsigned long, void (*)(vo= id*), 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_= node*) (tree.c:5264) >> by 0xA28ADC: build_builtin_function(unsigned int, char const*, tre= e_node*, int, built_in_class, char const*, tree_node*) (langhooks.c:681) >> by 0xA29FDD: add_builtin_function(char const*, tree_node*, int, bu= ilt_in_class, char const*, tree_node*) (langhooks.c:716) >> by 0x622BFB: def_builtin_1(built_in_function, char const*, built_i= n_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-buil= tins.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. (Actually, might use something like the "mitigated as follows" that I've added here: .) >>> 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? > > Well, instead of a final GC we could explicitly release all GC managed me= mory. Heh, of course, a "final GC at program end" doesn't help (much), given that (most of) all the blocks are still reachable via the usual GC roots. So I tried looking into how we might release all GCC memory unconditionally, via adapting 'ggc_mark_roots' (to not add back roots via 'ggc_mark_root_tab'), 'clear_marks', 'sweep_pages', 'release_pages', etc., but couldn't get this to work. It doesn't help, of course, that I don't know much about how the GC really works internally. Possibly my non-understanding of the "context depth" is highly relevant. Anyway, this isn't really important for me right now, having otherwise resolve my original issue, so I'm not intending to spend a lot more time on this. Calling 'memory_block_pool::trim (0);' at the end of 'gcc/main.c:main' does have some effect, too, but isn't sufficient/useful on its own, of course. 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