bug#43389: 28.0.50; Emacs memory leaks

[Eli Zaretskii]

> Cc: dj@redhat.com, 43389@debbugs.gnu.org
> From: Carlos O'Donell <carlos@redhat.com>
> Date: Tue, 17 Nov 2020 11:32:23 -0500
> 
> > "Small value" being something like 2?
> 
> The current code creates 8 arenas per core on a 64-bit system.
> 
> You could set it to 1 arena per core to force more threads into the 
> arenas and push them to reuse more chunks.
> 
> export MALLOC_ARENA_MAX=$(nproc)

Isn't that too many?  Emacs is a single-threaded program, with a small
number of GTK threads that aren't supposed to allocate a lot of
memory.  Sounds like 2 should be enough, no?

> > Any other suggestions or thoughts?
> 
> Yes, we have malloc trace utilities for capturing and simulating traces
> from applications:
> 
> https://pagure.io/glibc-malloc-trace-utils
> 
> If you can capture the application allocations with the tracer then we
> should be able to reproduce it locally and observe the problem.

You mean, trace all the memory allocations in Emacs with the tracer?
That would produce huge amounts of data, as Emacs calls malloc at an
insane frequency.  Or maybe I don't understand what kind of tracing
procedure you had in mind (I never used these tools, and didn't know
they existed until you pointed to them).

Thanks.