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

Previous Next

Package: emacs;

Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>

Date: Mon, 14 Sep 2020 00:44:01 UTC

Severity: normal

Merged with 43395, 43876, 44666

Found in version 28.0.50

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Trevor Bentley <trevor <at> trevorbentley.com>
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: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Mon, 30 Nov 2020 20:15:54 +0200
> From: Trevor Bentley <trevor <at> trevorbentley.com>
> Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, bugs <at> gnu.support,
>  dj <at> redhat.com, michael_heerdegen <at> web.de
> Cc: 
> Date: Mon, 30 Nov 2020 18:17:28 +0100
> 
>  3) I ran the built-in emacs profiler.  The profiler memory 
>  results are in the log

Thanks, but this doesn't really measure memory usage.  It just uses
malloc calls as a poor man's replacement for SIGPROF signal, so the
results show a kind of CPU profile, not memory profile.

>  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?

More like it's responsible for most of the CPU activity.

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

And the automatic GCs were much faster?

Thanks.  I hope Carlos will be able to give some hints based on your
data.




This bug report was last modified 4 years and 58 days ago.

Previous Next


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