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


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Trevor Bentley <trevor <at> trevorbentley.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
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: Thu, 10 Dec 2020 20:45:40 +0200
Stefan, please help with this complex issue (or maybe several
issues).  We have collected some evidence in this bug report, but I
don't yet see where is this going, or how to make any real progress
here.

One thing that I cannot explain is this:

> 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: Tue, 08 Dec 2020 22:50:37 +0100
> 
> I've been too busy to modify emacs to print garbage collects, but 
> these still show really long (garbage-collect) calls, often 
> exceeding 15 minutes.

Trevor reported several times that automatic GC is fast as usual, but
manual invocations of "M-x garbage-collect" take much longer, many
minutes.  I don't understand how this could happen, because both
methods of invoking GC do exactly the same job.

I thought about possible ways of explaining the stark differences in
the time it takes to GC, and came up with these:

 . The depth of the run-time (C-level) stack.  If this is much deeper
   in one of the cases, it could explain the longer time.  But in that
   case, I'd expect the automatic GC to take longer, because typically
   the C stack is relatively shallow when Emacs is idle than when it
   runs some Lisp.  This contradicts Trevor's observations.

 . Some difference in buffers and strings, which causes the manual GC
   to relocate and compact a lot of them.  But again: (a) why the
   automatic GC never hits the same condition, and (b) I can explain
   the reverse easier, i.e. that lots of temporary strings and buffers
   exist while Lisp runs, but not when Emacs is idle.

Any other ideas?  Any data Trevor could provide, e.g. by attaching a
debugger during these prolonged GC, and telling us something
interesting?

TIA




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.