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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: DJ Delorie <dj <at> redhat.com>
Cc: fweimer <at> redhat.com, carlos <at> redhat.com, 43389 <at> debbugs.gnu.org
Subject: Re: bug#43389: 28.0.50; Emacs memory leaks
Date: Tue, 17 Nov 2020 22:27:27 +0200

> From: DJ Delorie <dj <at> redhat.com>
> Cc: eliz <at> gnu.org, carlos <at> redhat.com, 43389 <at> debbugs.gnu.org
> Date: Tue, 17 Nov 2020 15:16:11 -0500
> 
> Florian Weimer <fweimer <at> redhat.com> writes:
> > But how helpful would that be, given that malloc_info does not really
> > show any inactive memory (discounting my 200 MiB hole)?
> 
> One doesn't know how helpful until after looking at the data.  If RSS is
> going up fast, something is calling either sbrk or mmap.  If that thing
> is malloc, a trace tells us if there's a pattern.  If that pattern
> blames the lisp allocator, my job here is done ;-)

I won't hold my breath for the lisp allocator to take the blame.  A
couple of people who were hit by the problem reported the statistics
of Lisp objects as produced by GC (those reports are somewhere in the
bug discussions, you should be able to find them).  Those statistics
indicated a very moderate amount of live Lisp objects, nowhere near
the huge memory footprint.

(It would be interesting to see the GC statistics from Florian's
session, btw.)

Given this data, it seems that if the Lisp allocator is involved, the
real problem is in what happens with memory it frees when objects are
GC'ed.

Previous Next

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