[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: |
Thu, 19 Nov 2020 16:03:51 +0200 |
> From: "Jose A. Ortega Ruiz" <jao@gnu.org>
> Date: Wed, 18 Nov 2020 21:47:30 +0000
>
> As an additional datapoint, since version 27 (i usually compile from
> master, so also before its release), i'm experiencing bigger RAM
> consumption from my emacs processes too.
>
> It used to always be way below 1Gb, and at some point (i have the
> impression it was with the switch to pdumper), typical footprints went
> up to ~2Gb.
>
> In my case, there seems to be a jump in RAM footprint every now and then
> (i get to ~1.5Gb in a day almost for sure, and 1.8Gb is not rare at
> all), but they're not systematic.
>
> Everything starts "normal" (300Mb), then i open Gnus an it grows a bit
> after reading some groups (500Mb, say), and so on, and be there for a
> while even if i keep using Gnus for reading similarly sized message
> groups. But, at some point, quite suddenly, i see RAM going to ~1Gb,
> without any obvious change in the libraries i've loaded or in my usage
> of them. The pattern repeats until i find myself with ~2Gb in N days,
> with N varying from 1 to 3.
>
> It's difficult for me to be more precise because i use emacs for
> absolutely everything. But, perhaps tellingly, i don't use most of the
> packages that have been mentioned in this thread (in my case it's ivy
> instead of helm, i use pdf-tools and that has a considerable footprint,
> but i see jumps without having it loaded too, similar thing for
> emacs-w3m), and i see the jumps to appear so consistently that my
> impression is that they're not directly caused by a single package.
Thanks. If you can afford it, would you please try using the malloc
tracing tools pointed to here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43389#158
and then tell us where we could get the data you collected?
> As i mentioned above, i've got a hunch that this all started, at least
> for me, with pdumper, but i must say that is most probably a red
> herring.
For the record, can you please tell what flavor and version of
GNU/Linux are you using?
> P.S.: I'm not copying the external GCC developers in this response
> because i think most of the above makes only sense to emacs developers;
> please let me know if you'd rather i did copy them.
I've added them. Please CC them in the future, it is important for us
that the glibc experts see the data points people report in this
matter.
- bug#43389: 28.0.50; Emacs memory leaks, (continued)
- bug#43389: 28.0.50; Emacs memory leaks, Eli Zaretskii, 2020/11/18
- bug#43389: 28.0.50; Emacs memory leaks, Carlos O'Donell, 2020/11/19
- bug#43389: 28.0.50; Emacs memory leaks, Eli Zaretskii, 2020/11/18
- bug#43389: 28.0.50; Emacs memory leaks, DJ Delorie, 2020/11/18
- bug#43389: 28.0.50; Emacs memory leaks, Carlos O'Donell, 2020/11/19
- bug#43389: 28.0.50; Emacs memory leaks, Deus Max, 2020/11/22
- bug#43389: 28.0.50; Emacs memory leaks, Eli Zaretskii, 2020/11/22
- bug#43389: 28.0.50; Emacs memory leaks, Deus Max, 2020/11/23
- bug#43389: 28.0.50; Emacs memory leaks, Eli Zaretskii, 2020/11/23
- Message not available
- bug#43389: 28.0.50; Emacs memory leaks, Jose A. Ortega Ruiz, 2020/11/18
- bug#43389: 28.0.50; Emacs memory leaks,
Eli Zaretskii <=
- bug#43389: 28.0.50; Emacs memory leaks, Jean Louis, 2020/11/19
- bug#43389: 28.0.50; Emacs memory leaks, Carlos O'Donell, 2020/11/19
- bug#43389: 28.0.50; Emacs memory leaks, jao, 2020/11/19
- Message not available
- bug#43389: 28.0.50; Emacs memory leaks, Eli Zaretskii, 2020/11/17
bug#43389: 28.0.50; Emacs memory leaks, Russell Adams, 2020/11/26