GNU bug report logs - #42482
27.0.91; emacs modules memory leak

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Milan Stanojević <mstanojevic <at> janestreet.com>
Subject: bug#42482: closed (Re: bug#42482: 27.0.91; emacs modules memory leak)
Date: Thu, 23 Jul 2020 12:08:01 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#42482: 27.0.91; emacs modules memory leak

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 42482 <at> debbugs.gnu.org.

-- 
42482: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=42482
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Milan Stanojević <mstanojevic <at> janestreet.com>
Cc: 42482-done <at> debbugs.gnu.org
Subject: Re: bug#42482: 27.0.91; emacs modules memory leak
Date: Thu, 23 Jul 2020 14:06:57 +0200

Am Do., 23. Juli 2020 um 01:27 Uhr schrieb Milan Stanojević
<mstanojevic <at> 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.

[Message part 3 (message/rfc822, inline)]

From: Milan Stanojević <mstanojevic <at> janestreet.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.91; emacs modules memory leak
Date: Wed, 22 Jul 2020 19:25:19 -0400

[Message part 4 (text/plain, inline)]

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.

[create_global_refs.c (text/x-csrc, attachment)]

[create_global_refs_test.el (text/x-emacs-lisp, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.