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: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#42482: closed (27.0.91; emacs modules memory leak)
Date: Thu, 23 Jul 2020 12:08:01 +0000

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

Your message dated Thu, 23 Jul 2020 14:06:57 +0200
with message-id <CAArVCkQHSYWscek=GPhwixCmy8jg4fk3y-ZYxRkWcY9HbAzJBw <at> mail.gmail.com>
and subject line Re: bug#42482: 27.0.91; emacs modules memory leak
has caused the debbugs.gnu.org bug report #42482,
regarding 27.0.91; emacs modules memory leak
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> 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: 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 3 (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)]

[Message part 6 (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.

Previous Next

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