bug#43389: 28.0.50; Emacs memory leaks

[Eli Zaretskii]

> From: Trevor Bentley <trevor@trevorbentley.com>
> Cc: 43389@debbugs.gnu.org
> Date: Wed, 11 Nov 2020 22:15:21 +0100
> 
> The raw massif output:
> 
> http://trevorbentley.com/massif.out.3364630
> 
> The *full* tree output:
> 
> http://trevorbentley.com/ms_print.3364630.txt
> 
> The tree output showing only entries above 10% usage:
> 
> http://trevorbentley.com/ms_print.thresh10.3364630.txt
> 
> What you can see from the handy ASCII graph at the top is that 
> memory usage was chugging along, growing upwards for a couple of 
> days, and then spiked very quickly up to just over 4GB over a few 
> hours.

When this pick happens, I see the following unusual circumstances:

  . ImageMagick functions are called and request a lot of (aligned)
    memory;
  . something called "gomp_thread_start" is called, and also allocates
    a lot of memory -- does this mean additional threads start running?

Or am I reading the graphs incorrectly?

Also, I see that you are using the native-compilation branch, and
something called slack-image is being loaded?  What is this about?

And can you tell me whether src/config.h defines DOUG_LEA_MALLOC to a
non-zero value on that system?

> If you scroll down to the very last checkpoint (the 10% threshold 
> file is better for this), you can see where most of the memory is 
> used.  Very large sums of memory, but from different sources. 
> 1.7GB from lisp_align_malloc (nearly all from Fcons), 1.4GB from 
> lmalloc (half from allocate_vector_block), 700MB from lrealloc 
> (mostly from enlarge_buffer_text).
> 
> There were no large buffers open, but there were long-lived 
> network sockets and plenty of timers.  I didn't check, but I'd say 
> the largest buffer was up to a couple of megabytes, since 
> emacs-slack logs fairly heavily.
> 
> I'm not sure what to make of this, really.  It seems like a 
> general, sudden-onset, intense craving for more memory while not 
> particularly doing much.  I could blindly suggest extreme memory 
> fragmentation problems, but that doesn't seem very likely.

It is important to understand what was going one when the memory
started growing fast.  You say there were no large buffers, but what
about temporary buffers? what could cause gomp_thread_start, whatever
that is, to start?

We recently added a malloc-info command, maybe you could use it to
show more information about the malloc arenas before and after it
starts to eat up memory.