bug#43389: 28.0.50; Emacs memory leaks

[Eli Zaretskii]

> From: DJ Delorie <dj@redhat.com>
> Cc: eliz@gnu.org, carlos@redhat.com, 43389@debbugs.gnu.org
> Date: Tue, 17 Nov 2020 15:16:11 -0500
> 
> Florian Weimer <fweimer@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.