Re: Memory leaks (detected by Valgrind)

[David Malcolm <dmalcolm@redhat.com>]

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

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