bug#43389: 28.0.50; Emacs memory leaks

[Eli Zaretskii]

> From: Florian Weimer <fweimer@redhat.com>
> Cc: carlos@redhat.com,  dj@redhat.com,  43389@debbugs.gnu.org
> Date: Tue, 17 Nov 2020 17:33:13 +0100
> 
>    <size from="1065345" to="153025249" total="226688532" count="20"/>
> 
>    <total type="fast" count="0" size="0"/>
>    <total type="rest" count="3802" size="238948201"/>
> 
> Total RSS is 1 GiB, but even 1 GiB minus 200 MiB would be excessive.

Yes, I wouldn't expect to see such a large footprint.  How long is
this session running?  (You can use "M-x emacs-uptime" to answer
that.)

> It's possible to generate such statistics using GDB, by calling the
> malloc_info function.

Emacs 28 (from the master branch) has recently acquired the
malloc-info command which will emit this to stderr.  You can see one
example of its output here:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44666#5

which doesn't seem to show any significant amounts of free memory at
all?

I encourage all the people who reported similar problems to try the
measures mentioned by Florian and Carlos, including malloc-info, and
report the results.

> My Emacs process does not look like it suffered from the aligned_alloc
> issue.  It would leave behind many smaller, unused allocations, not such
> large ones.
> [...]
> >> supported by the system.  Setting MALLOC_ARENA_MAX to a small value
> >> counteracts that, so it's very simple to experiment with it if you have
> >> a working reproducer.
> >
> > "Small value" being something like 2?
> 
> Yes, that would be a good start.  But my Emacs process isn't affected by
> this, so this setting wouldn't help there.

So both known problems seem to be not an issue in your case.  What
other reasons could cause that?