Re: Memory leaks (detected by Valgrind)

["Marc Nieper-Wißkirchen" <marc.nieper+gnu@gmail.com>]

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 <jit-bounces+alex.coplan=arm.com@gcc.gnu.org> On Behalf
> > > Of Marc
> > > Nieper-Wißkirchen via Jit
> > > Sent: 17 December 2021 10:29
> > > To: Mark Wielaard <mark@klomp.org>
> > > Cc: Marc Nieper-Wißkirchen <marc.nieper+gnu@gmail.com>;
> > > 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.

>
> 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!

[...]