[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#43389: 28.0.50; Emacs memory leaks
From: |
Eli Zaretskii |
Subject: |
bug#43389: 28.0.50; Emacs memory leaks |
Date: |
Tue, 17 Nov 2020 19:08:24 +0200 |
> 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?
- bug#43389: 28.0.50; Emacs memory leaks, (continued)
- bug#43389: 28.0.50; Emacs memory leaks, Jean Louis, 2020/11/10
- bug#43389: 28.0.50; Emacs memory leaks, Trevor Bentley, 2020/11/11
- bug#43389: 28.0.50; Emacs memory leaks, Eli Zaretskii, 2020/11/12
- bug#43389: 28.0.50; Emacs memory leaks, Eli Zaretskii, 2020/11/16
- bug#43389: 28.0.50; Emacs memory leaks, Florian Weimer, 2020/11/16
- bug#43389: 28.0.50; Emacs memory leaks, Eli Zaretskii, 2020/11/17
- bug#43389: 28.0.50; Emacs memory leaks, Florian Weimer, 2020/11/17
- bug#43389: 28.0.50; Emacs memory leaks,
Eli Zaretskii <=
- bug#43389: 28.0.50; Emacs memory leaks, Florian Weimer, 2020/11/17
- bug#43389: 28.0.50; Emacs memory leaks, Jean Louis, 2020/11/17
- bug#43389: 28.0.50; Emacs memory leaks, DJ Delorie, 2020/11/17
- bug#43389: 28.0.50; Emacs memory leaks, Jean Louis, 2020/11/17
- bug#43389: 28.0.50; Emacs memory leaks, Eli Zaretskii, 2020/11/18
- bug#43389: 28.0.50; Emacs memory leaks, Jean Louis, 2020/11/23
- bug#43389: 28.0.50; Emacs memory leaks, Carlos O'Donell, 2020/11/17
- bug#43389: 28.0.50; Emacs memory leaks, Eli Zaretskii, 2020/11/17
- bug#43389: 28.0.50; Emacs memory leaks, DJ Delorie, 2020/11/17
- bug#43389: 28.0.50; Emacs memory leaks, Eli Zaretskii, 2020/11/17