bug#43389: 28.0.50; Emacs memory leaks using hard disk all time

[Eli Zaretskii]

> From: Trevor Bentley <trevor@trevorbentley.com>
> Cc: bugs@gnu.support, fweimer@redhat.com, 43389@debbugs.gnu.org,
>  dj@redhat.com, michael_heerdegen@web.de, carlos@redhat.com
> Date: Wed, 25 Nov 2020 11:22:16 +0100
> 
> >>  - The leaking stops for a while after (garbage-collect).  It 
> >>  was  leaking 1MB per second for this last log, and stopped 
> >>  growing  after the garbage collection. 
> > 
> > Now, what happens in that session once per second (in an 
> > otherwise idle Emacs, I presume?) to cause such memory 
> > consumption?  Some timers?  If you run with a breakpoint in 
> > malloc that just shows the backtrace and continues, do you see 
> > what could consume 1MB every second? 
> 
> Not an idle emacs at all, in this case.  I have seen the memory 
> growth in an idle emacs, but the only one I can reproduce it on is 
> the emacs-slack one, which is connected to a corporate Slack 
> account.  Tons of short messages streaming in over the network and 
> being displayed in rotating buffers, with images mixed in.  It's a 
> big 'ol "web 2.0" API... it can easily pass 1MB/s of bloated JSON 
> messages through.  This is one _very active_ emacs.

Then I don't think we will be able to understand what consumes memory
at such high rate without some debugging.  Have you considered using
breakpoints and collecting backtraces, as I suggested earlier?

The hard problem is to understand which memory is allocated and not
freed "soon enough", but for such a high rate of memory consumption
perhaps just knowing which code request so much memory would be an
important clue.

> The original strace logs and valgrind output I posted before 
> showed a random assortment of calls from gnutls, imagemagick, and 
> lisp strings, with lisp strings dominating the malloc calls 
> (enlarge_buffer_text, mostly).

Enlarging buffer text generally causes malloc to call mmap (as opposed
to brk/sbrk), so this cannot cause the situation where a lot of unused
memory that is not returned to the OS.  And we already saw that just
by summing up the buffer text memory we never get even close to the VM
size of the process.

> > What do you mean by "reaping dead references" here? 
> > 
> >> It could be that there really were 4.3GB of dead references. 
> > 
> > Not sure I understand what are you trying to establish here. 
> 
> GC is running through a list of active allocations and freeing the 
> ones with no remaining references, right?  Presumably, if a lot of 
> active malloc() allocations are no longer refernced, and 
> (garbage-collect) calls free() on a bunch of blocks.

We only call free on "unfragmented" Lisp data, e.g. if some block of
Lisp strings was freed in its entirety.  If some Lisp objects in a
block are still alive, we don't free the block, we just mark the freed
Lisp objects as being free and available for reuse.

So the result of GC shows only tells you how much of the memory was
freed but NOT returned to glibc, it doesn't show how much was actually
free'd.

> I'm wondering how to figure out how much memory a call to
> (garbage-collect) has actually freed.  Possibly a sort of "dry run"
> where it performs the GC algorithm, but doesn't release any memory.

"Freed" in what sense? returned to glibc?

> > There's only one garbage-collect, it is called for _any_ GC. 
> > 
> > What do you mean by "during normal use" in this sentence: 
> > 
> >   I certainly don't notice 5-10 minute long pauses during normal 
> >   use, though "gcs-done" is incrementing. 
> > 
> > How is what you did here, where GC took several minutes, 
> > different from "normal usage"?
> 
> In this log, I am explicitly executing "(garbage-collect)", and it 
> takes 10 minutes, during which the UI is unresponsive and 
> sometimes even turns grey when the window stops redrawing.
> 
> By "normal use", I mean that I use this emacs instance on-and-off 
> all day long.  I would notice if it were freezing for minutes at a 
> time, and it definitely is not.
> 
> As far as I understand, garbage collection is supposed to happen 
> automatically during idle.  I would certainly notice if it locked 
> up the whole instance for 10 minutes from an idle GC.  I think 
> this means the automatic garbage collection is either not 
> happening, or running on a different thread, or being interrupted, 
> or simply works differently.  I have no idea, hence asking you :)

That is very strange.  There's only one function to perform GC, and it
is called both from garbage-collect and from an internal function
called when Emacs is idle or when it calls interpreter functions like
'eval' or 'funcall'.  The only thing garbage-collect does that the
internal function doesn't is generate the list that is the return
value of garbage-collect, but that cannot possibly take minutes.

I suggest to set garbage-collection-messages non-nil, then you should
see when each GC, whether the one you invoke interactively or the
automatic one, starts and ends.  maybe the minutes you wait are not
directly related to GC, but to something else that is triggered by GC?