From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) by sourceware.org (Postfix) with ESMTPS id 96205383B42B for ; Fri, 6 Aug 2021 15:10:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 96205383B42B Received: by mail-wm1-x329.google.com with SMTP id d131-20020a1c1d890000b02902516717f562so6353161wmd.3 for ; Fri, 06 Aug 2021 08:10:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:user-agent:in-reply-to :references:message-id:mime-version:content-transfer-encoding; bh=9aaNxHr25mEeJSrv6aYUNQg8nkqknt/0AAOKCvKxl6Q=; b=X3DrEJhA+r443u0cy5n2P8OQG3ZaaCdNETWPhEeLHSUKf6HOsZoOZmIKuDbeb25Nl0 6LsVH58NuzEk9XAgZznMPeaexr6jYYT/22RYmlRZyyBUBCCWuqtox067HHoYGat6YUm7 ez7cB2hUgmnw+tQYgJRl5ooItCwdnhs4bcPw5dctvq7NZlTrb2e8/RTZwkAjO8Xj8Pge L69qiZ+tHjbwLkA0XGMvsHILVHDJR5c84lJojIw6q5m0YkKbRKvIz8dAa/MdVYDQiJY0 jkATy3719qyvKZaMrvkuVL9duicFEZbPP6upymJYvnJqcXoQ8PbSfaqmUGd3zMJeAUEZ H9DA== X-Gm-Message-State: AOAM5302Ue+kXUFfpxVNk+PKejmIahrhehinbk1lOK15lU+//AeYP4uQ byx5hFCixku8URgIaQ5FRfk= X-Google-Smtp-Source: ABdhPJxDBoeVZt1p6WgBy78ejcmWmJCnuux/wLogFkL7sCRegzkzn2jWfUJKFvV4GBsYrkTns/n6lw== X-Received: by 2002:a7b:cbcd:: with SMTP id n13mr3645163wmi.105.1628262638628; Fri, 06 Aug 2021 08:10:38 -0700 (PDT) Received: from [127.0.0.1] (dynamic-095-114-068-240.95.114.pool.telefonica.de. [95.114.68.240]) by smtp.gmail.com with ESMTPSA id k17sm9877909wrw.53.2021.08.06.08.10.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Aug 2021 08:10:38 -0700 (PDT) Date: Fri, 06 Aug 2021 17:10:36 +0200 From: Richard Biener To: Thomas Schwinge , gcc-patches@gcc.gnu.org, Martin Sebor Subject: Re: Valgrind '--show-leak-kinds=all' User-Agent: K-9 Mail for Android In-Reply-To: <87im0ihdge.fsf@euler.schwinge.homeip.net> References: <3d205f84-c076-0388-ad60-24cd94d61696@gmail.com> <23a920e2-a6e2-f7db-8e75-ff6224f732d2@gmail.com> <87im0ihdge.fsf@euler.schwinge.homeip.net> Message-ID: <17082A31-CA8B-4FF0-B36B-A6D754B1BCB0@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, 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 15:10:41 -0000 On August 6, 2021 4:09:37 PM GMT+02:00, Thomas Schwinge wrote: >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 wr= ote: >>> >> [=2E=2E=2E] 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=2E >>> >> >>> >> 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=2E >>> >> >>> >> 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=2E >>> >>> 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=2Edg/Wvla-parameter=2Ec -wrapper >>> valgrind,--leak-check=3Dfull,--show-leak-kinds=3Dall,--track-origins= =3Dyes,--log-file=3Dvalgrind-out=2Etxt >>> >>> 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=2Ec:762) > by 0x1753240: xcalloc (xmalloc=2Ec:162) > by 0x669C83: ggc_internal_alloc(unsigned long, void (*)(void*), un= signed long, unsigned long) (ggc-page=2Ec:918) > by 0x89E07D: ggc_internal_cleared_alloc(unsigned long, void (*)(vo= id*), unsigned long, unsigned long) (ggc-common=2Ec:117) > by 0xF65D0D: make_node(tree_code) (ggc=2Eh:143) > by 0xF6632B: build_decl(unsigned int, tree_code, tree_node*, tree_= node*) (tree=2Ec:5264) > by 0xA28ADC: build_builtin_function(unsigned int, char const*, tre= e_node*, int, built_in_class, char const*, tree_node*) (langhooks=2Ec:681) > by 0xA29FDD: add_builtin_function(char const*, tree_node*, int, bu= ilt_in_class, char const*, tree_node*) (langhooks=2Ec: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= =2Econstprop=2E25] (lto-lang=2Ec:650) > by 0x640709: lto_define_builtins(tree_node*, tree_node*) (omp-buil= tins=2Edef:46) > by 0x641EE3: lto_init() (lto-lang=2Ec:1339) > by 0x61E26A: toplev::main(int, char**) (toplev=2Ec:1921) > >=2E=2E=2E and many, many more=2E > >> Err, well=2E --show-leak-kinds=3Dall is probably the cause=2E > >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=2E > >=2E=2E=2E of this: these blocks simply had not been GCed at program end= =2E > >It's however a bit tedious to filter, in my case, 11864 lines of Valgrind >output=2E > >> Not sure if >> valgrind annotations can >> make that obvious to valgrind=2E > >Or, if that's not feasible (I don't know much about Valgrind=2E=2E=2E), t= hen >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 mem= ory=2E=20 >> I'm just using --leak-check=3Dfull and >> thus look for >> unreleased and no longer reachable memory=2E > >ACK, in my case, that only shows seven errors (not related to my stuff)= =2E > > >Gr=C3=BC=C3=9Fe > Thomas >----------------- >Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 2= 01, 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch= =C3=A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellsc= haft: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955