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

Previous Next

Full log

Message #464 received at 43389 <at> debbugs.gnu.org (full text, mbox):

From: Trevor Bentley <trevor <at> trevorbentley.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, bugs <at> gnu.support, dj <at> redhat.com,
 carlos <at> redhat.com, michael_heerdegen <at> web.de, 
Subject: Re: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Tue, 24 Nov 2020 20:05:15 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> Look at the large chunks in the tail of this.  Together, they do 
> account for ~2GB. 
> 
> Carlos, are these chunks in use (i.e. allocated and not freed), 
> or are they the free chunks that are available for allocation, 
> but not released to the OS?  If the former, then it sounds like 
> this session does have around 2GB of allocated heap data, so 
> either there's some allocated memory we don't account for, or 
> there is indeed a memory leak in Emacs.  If these are the free 
> chunks, then the way glibc manages free'd memory is indeed an 
> issue. 

I just updated the log on my website.  Same instance a day later, 
after yet another memory spike up to 4.3GB.  Concatenated to the 
end:

https://trevorbentley.com/emacs_malloc_info.log

Some interesting observations:
- (garbage-collect) takes forever, like on the order of 5-10 
minutes, with one CPU core pegged to 100% and emacs frozen.
- The leaking stops for a while after (garbage-collect).  It was 
leaking 1MB per second for this last log, and stopped growing 
after the garbage collection.

Question 1: (garbage-collect) shows the memory usage *after* 
collecting, right?  Is there any way to get the same info without 
actually reaping dead references?  It could be that there really 
were 4.3GB of dead references.

Question 2: are the background garbage collections equivalent to 
the (garbage-collect) function?  I certainly don't notice 5-10 
minute long pauses during normal use, though "gcs-done" is 
incrementing.  Does it have a different algorithm for partial 
collection during idle, perhaps?

Question 3: I've never used the malloc_trim() function.  Could 
that be something worth experimenting with, to see if it releases 
any of the massive heap back to the OS?

-Trevor

Previous Next

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