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

Previous Next

Full log

View this message in rfc822 format

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

> I'll have an mtrace for you from the current experiment (X11 
> focus  leak) tomorrow or Monday.  I hope it's the same issue. 

Ok, here is my latest memory log and a matching libmtrace:

https://trevorbentley.com/mtrace3/

This capture is unique in three ways:
1) Compared to my other tests, this one did not run emacs-slack 
and did about half of its leaking from X11 focus events, and the 
other half drifting upwards during idle.  This session has barely 
done anything.

2) I added a custom (malloc-trim) command, and called it after 
making my standard memory log.  At the end of the log, you can 
see that after the trim memory usage fell from 4GB to 50MB. 
Unfortunately, this malloc_trim() might make the libmtrace trace 
harder to make sense of.  But, at least in this case, it meant 
99% of the memory could be given back to the OS?

3) I ran the built-in emacs profiler.  The profiler memory 
results are in the log, both in normal and reversed format, with 
the largest element expanded.  I don't know how to interpret it, 
but it looks like maybe a periodic timer started by helm is 
responsible for 3+GB of RAM?

Also note that the (garbage-collect) call is timed now.  318 
seconds for this one.

-Trevor

Previous Next

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