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

From: Eli Zaretskii <[email-masked]>
Date: Mon, 23 Nov 2020 17:46:16 +0200

> Date: Mon, 23 Nov 2020 13:59:47 +0300
> From: Jean Louis <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked],
>   [email-masked], [email-masked], [email-masked]
> 
> In the IceWM window manager I have visual representation of memory
> usage and that is how I get feeling, there is also tooltip telling me
> that more and more memory is used. When it starts to swap like 3 GB
> then I turn on symon-mode and in Emacs I see more and more swapping.

I think I described how to write an Emacs function that you could use
to watch the vsize of the Emacs process and alert you to it being
above some threshold.

> The heap file is here 24M, maybe not needed for review:
> https://gnu.support/files/tmp/2020-11-23/jeprof.23826.0.f.heap
> 
> Visualization is here 20K PDF file:
> https://gnu.support/files/tmp/2020-11-23/jeprof.23826.0.f.heap.pdf
> 
> Do you see anything interesting inside that should tell about memory leaks?

I'm not sure.  I think I see that you have some timer that triggers a
lot of memory allocations because it conses a lot of Lisp objects.
Whether that is part of the problem or not is not clear.

Next time when your session causes the system to swap, please type:

  M-: (garbage-collect) RET

and post here the output of that (it should be a list of numbers
whose meanings are explained in the doc string of garbage-collect).

Also, I think I asked to tell how large are your buffers by evaluation
the following (again, near the point where your session causes the
system to page heavily):

  (let ((size 0))
    (dolist (buffer (buffer-list) size)
      (setq size (+ size (buffer-size buffer)))))

It is important to have both these pieces of information from the same
session at the same time near the point where you must kill Emacs, so
that we know how much memory is actually used by your session at that
point (as opposed to memory that is "free" in the heap, but was  not
returned to the OS).

Thanks.