From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 2F2863858D28 for ; Sat, 18 Dec 2021 16:45:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2F2863858D28 Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-231-Dry5o46sNFa01dUtMMkY4Q-1; Sat, 18 Dec 2021 11:45:23 -0500 X-MC-Unique: Dry5o46sNFa01dUtMMkY4Q-1 Received: by mail-qv1-f71.google.com with SMTP id r13-20020a0562140c8d00b003bde7a2b8e2so5526059qvr.6 for ; Sat, 18 Dec 2021 08:45:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=mfmIj9aYSs7IyNoKAsGfIZ8iEoQ4LgRNzYowR95u2Ek=; b=lkUfOWHqWkZzoOdS3BHAvlc+RrSZL9oIoTtyhRR1K1ajD/927slovUb+B6eNWXLaOt avtxNOHXL0WDd7ZeEd7U7yfunmV9To8VgJ/Sopx/lolGLfbjS251c8s4wRAp8mKGfeAS pH+lTNBwF4pRB0ISxI6vKWaytRDtSxDZpylVCWWVI97S7cNf17Nj1yUPvnEKZVIdZE8H dEa+uhQfgeDefFjpndrJaPhIwJIWwZLixDOXJQY6USJ5v2Mg0YynX8o40UtHAw+DotoL NjPEay77b1dpfF20s8106O6N8OvBeu7jsg0UplpWKTvAgzeZTVikouphsZsBUy9J4T9d XC9w== X-Gm-Message-State: AOAM532aH5zAsfWLtYJApQr/6MXBCrhRDMk30SefQtlMLA26M+/rWCLW 5kghbc/60F/592AUxGFXj7mikkvj74YBen4YH7Krg92vbanbkCx5jIJXmQH1FSU+DaOyqRc3jXF g779CBJ4= X-Received: by 2002:a0c:c24d:: with SMTP id w13mr7120403qvh.102.1639845923368; Sat, 18 Dec 2021 08:45:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJz0X3wgiSYQhhH+4C1BZ7WFW60tLv0aXpCV2wcybjMpAHP7W9iTC1ibAcJqKdTuMzx9gfk+Bw== X-Received: by 2002:a0c:c24d:: with SMTP id w13mr7120394qvh.102.1639845923172; Sat, 18 Dec 2021 08:45:23 -0800 (PST) Received: from t14s.localdomain (c-73-69-212-193.hsd1.nh.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id az16sm7619782qkb.124.2021.12.18.08.45.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Dec 2021 08:45:22 -0800 (PST) Message-ID: <07714a8d9583dd2ebfe548f5c066d6d2213434d7.camel@redhat.com> Subject: Re: Memory leaks (detected by Valgrind) From: David Malcolm To: Marc =?ISO-8859-1?Q?Nieper-Wi=DFkirchen?= Cc: Alex Coplan , Mark Wielaard , "jit@gcc.gnu.org" , Joseph Myers Date: Sat, 18 Dec 2021 11:45:18 -0500 In-Reply-To: References: User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: jit@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Jit mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2021 16:45:29 -0000 On Sat, 2021-12-18 at 14:57 +0100, Marc Nieper-Wißkirchen wrote: > Am Sa., 18. Dez. 2021 um 00:23 Uhr schrieb David Malcolm < > dmalcolm@redhat.com>: > > > > On Fri, 2021-12-17 at 10:52 +0000, Alex Coplan via Jit wrote: > > > Hi, > > > > > > > -----Original Message----- > > > > From: Jit On > > > > Behalf > > > > Of Marc > > > > Nieper-Wißkirchen via Jit > > > > Sent: 17 December 2021 10:29 > > > > To: Mark Wielaard > > > > Cc: Marc Nieper-Wißkirchen ; > > > > jit@gcc.gnu.org > > > > Subject: Re: Memory leaks (detected by Valgrind) > > > > > > > > Thanks! > > > > > > > > With `--enable-valgrind-annotations`, the "uses of > > > > uninitialized > > > > values" > > > > have gone away, but a lot of small leaks are still present: > > > > > > Memory leaks with libgccjit are a known issue, see > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63854 > > > > FWIW, it looks like all of the remaining leaks are in gcc.c (the > > "driver" code, for the "gcc" binary).   IIRC most of this relates > > to > > long-standing code that was written with the assumption that it > > will > > only be run once and not persist in memory, and so it tends to mix > > up > > string literals and dynamically-allocated strings without bothering > > to > > free them (the pointer values persist to the end of "main" when run > > from gcc, but get cleared when run from libgccjit.so). > > > > Patches to clean these up would be great.  That said, I'm not the > > driver/gcc.c maintainer, so I can't formally approve them (but can > > post > > +1 emails if they look good to me)  [1] > > I am currently trying to find my way through the code in gcc.c. > During > my experiments, I fixed a single leak where a dynamically allocated > string was assigned in place of a statically allocated one by moving > the dynamically allocated string onto the obstack. I hope that such > an > approach is acceptable. IIRC I tried that approach, and the maintainer (Joseph Myers, I think), wasn't keen on it, but this was a few years ago. I've tried finding the discussion in the archives, but couldn't. IIRC, he preferred adding a flag to strings in gcc.c, tracking if they needed to be freed. I'm CCing Joseph. FWIW there's a class in libcpp/include/line-map.h: class label_text which does this. Perhaps it could be used for this (and maybe renamed???) Commit 9376dd63e6a2d94823f6faf8212c9f37bef5a656 added the code to run gcc.c in-process (before it was run in a subprocess), so maybe the discussion was some time around then? (2015-08-25) Note that it's still possible to run this code in a subprocess rather than in-process (and thus workaround the leak) using gcc_jit_context_set_bool_use_external_driver. > > > > > Dave > > > [1] also, I'm on vacation, so sorry in advance for any slow > > responses > > to email. > > I wish you a good time on your vacation! Thanks! Dave