bug#43389: 28.0.50; Emacs memory leaks

[Eli Zaretskii]

[Please use Reply All to keep the bug tracker on the CC list.]

> From: Trevor Bentley <trevor@trevorbentley.com>
> Cc: 
> Date: Tue, 17 Nov 2020 21:22:52 +0100
> 
> >   . 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? 
> 
> You are right that they are present, but that path isn't 
> responsible for a significant percentage of the total memory usage 
> at the end.  Doesn't look like gomp_thread_start is in the 
> bottom-most snapshot at all.  It was reporting ~100MB allocated by 
> gomp_thread_start, out of 4GB.  And those are related to images, 
> so 100MB is perhaps reasonable.

AFAIK, glibc's malloc allocates a new heap arena for each thread that
calls malloc.  The arena is large, so having many threads could
enlarge the footprint by a lot.  That's hwy Florian suggested to set
MALLOC_ARENA_MAX to a small value, to keep this path of footprint
growth in check.
> However, I'm now a bit suspicious of these log buffers.  Last time 
> the usage spiked I had 15MB of reported buffers, and I was 
> watching the process RSS increase by 1MB every 5 seconds in top, 
> like a clockwork.  I killed all of the large log buffers (3MB 
> each), and RSS stopped noticeably increasing.  Not sure if that 
> _stopped_ the leak, or only slowed it down to beneath the 
> threshold top could show me.  Either way, it should need 1.5GB of 
> RAM to track 15MB of text.

Unless malloc somehow allocates buffer memory via sbrk and not mmap,
buffers shouldn't be part of the footprint growth issue, because any
mmap'ed memory can be munmap'ed without any restrictions, and returns
to the OS.  And you can see how many buffer memory you have by
watching the statistics returned by garbage-collect.

> gomp_thread_start appears to be triggered when images are 
> displayed.

Yes, I believe ImageMagick starts them to scale images.