GNU bug report logs - #43389
28.0.50; Emacs memory leaks

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: fweimer <at> redhat.com, carlos <at> redhat.com, dj <at> redhat.com
Cc: 43389 <at> debbugs.gnu.org
Subject: bug#43389: 28.0.50; Emacs memory leaks
Date: Mon, 16 Nov 2020 22:16:12 +0200

Bringing on board of this discussion glibc malloc experts: Florian
Weimer, DJ Delorie, and Carlos O'Donell.

For some time (several months, I think) we have reports from Emacs
users that the memory footprints of their Emacs sessions sometimes
start growing very quickly, from several hundreds of MBytes to several
gigabytes in a day or even just few hours, and in some cases causing
the OOMK to kick in and kill the Emacs process.  Please refer to the
details described in the discussions of this bug report:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43389

and 3 other bugs merged to it, which describe what sounds like the
same problem.

The questions that I'd like to eventually be able to answer are:

  . is this indeed due to some malloc'ed chunk that is being used for
    prolonged periods of time, and prevents releasing parts of the
    heap to the system?  IOW, is this pathological, but correct
    behavior, or is this some bug?

  . if this is correct behavior, can Emacs do something to avoid
    triggering it?  For example, should we consider tuning glibc's
    malloc in some way, by changing the 3 calls to mallopt in
    init_alloc_once_for_pdumper?

Your thoughts and help in investigating these problems will be highly
appreciated.  Please feel free to ask any questions you come up with,
including about the details of Emacs's memory management and anything
related.

Thanks!

Previous Next

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