bug#42482: 27.0.91; emacs modules memory leak

[Philipp Stephani]

Am Do., 23. Juli 2020 um 16:29 Uhr schrieb Milan Stanojević
<mstanojevic@janestreet.com>:
>
> Thank you for the quick fix.
> Is there a chance this also goes to emacs-27 branch so it can be in
> the emacs 27.1 when it gets released?

I think backporting the fix should be fine, as the fix is rather
localized and fixes a regression. Eli?

>
> On Thu, Jul 23, 2020 at 8:07 AM Philipp Stephani <p.stephani2@gmail.com> 
> wrote:
> >
> > Am Do., 23. Juli 2020 um 01:27 Uhr schrieb Milan Stanojević
> > <mstanojevic@janestreet.com>:
> > >
> > > env-make_global_ref adds a reference to the underlying Lisp_Object
> > > and allocates emacs_value from the global storage. env->free_global_ref
> > > on the other hand will only remove a reference to the underlying
> > > Lisp_Object and not free the emacs_value.
> > >
> > > Here is a simple recipe to reproduce the problem (I only tested this
> > > on linux). I'm attaching the necessary files.
> > >
> > > $ gcc -shared -fpic -std=c99 -I <dir-with-emacs-module.h>
> > > create_global_refs.c -o create_global_refs.so
> > > $ emacs --no-splash -q -l create_global_refs.so -l 
> > > create_global_refs_test.el
> > >
> > > If you look at the memory usage of emacs (for example in htop) you'll
> > > see that with emacs-26 it is constant but with emacs-27 the resident
> > > memory quickly grows.
> >
> > Thanks for the report. I've fixed this in commit
> > 5c5eb9790898e4ab10bcbbdb6871947ed3018569; the fix is slightly
> > different from what you proposed in that it stores the emacs_value
> > object in the global references hashtable, but it should have the same
> > effect. At least I can't reproduce the symptom any more after that
> > commit.