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: Carlos O'Donell <carlos <at> redhat.com>
Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, dj <at> redhat.com
Subject: bug#43389: 28.0.50; Emacs memory leaks
Date: Wed, 18 Nov 2020 20:01:48 +0200
> Cc: dj <at> redhat.com, 43389 <at> debbugs.gnu.org
> From: Carlos O'Donell <carlos <at> redhat.com>
> Date: Wed, 18 Nov 2020 00:43:55 -0500
> 
> >> (let ((size 0))
> >>   (dolist (buffer (buffer-list) size)
> >>     (setq size (+ size (buffer-size buffer)))))
> >> ⇒ 98249826
> >>
> >> So it's not a small number, but still far away from those 800 MiB.
> > 
> > Yes.  I have a very similar value: 94642916 (in 376 buffers; you have
> > more than 1000).  This is in a session that runs for 17 days and whose
> > VM size is 615 MB: a "normal" size for a long-living session, nowhere
> > near 2GB, let alone 11GB someone reported.
> 
> If you get us a data trace I will run it through the simulator and produce
> a report that includes graphs explaining the results of the trace and
> we'll see if a smoking gun shows up.

If you asked Florian, then I agree that his data could be useful.  If
you were asking me, then my data is not useful, because the footprint
is reasonable and never goes up to gigabyte range.




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.