[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#43389: 28.0.50; Emacs memory leaks
From: |
Carlos O'Donell |
Subject: |
bug#43389: 28.0.50; Emacs memory leaks |
Date: |
Thu, 19 Nov 2020 11:08:56 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 |
On 11/18/20 1:27 PM, DJ Delorie wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>> If you asked Florian, then I agree that his data could be useful. If
>> you were asking me, then my data is not useful, because the footprint
>> is reasonable and never goes up to gigabyte range.
>
> Yeah, the hard part here is capturing the actual problem. I'm running
> the latest Emacs too but haven't seen the growth. Traces tend to be
> more useful when the problem is reproducible in situ but really hard to
> reproduce in a test environment.
My commitment is this: If anyone can reproduce the problem with the tracer
enabled then I will analyze the trace and produce a report for the person
submitting the trace.
The report will include some graphs, and an analysis of the API calls and
the resulting RSS usage.
I've written several of these reports, but so far they haven't been all
that satisfying to read. We rarely find an easily discoverable root cause.
We probably need better information on the exact lifetimes of the the
allocations.
For example I recently added a "caller" frame trace which uses the dwarf
unwinder to find the caller and record that data. It's expensive and on
only if requested. This is often useful in determining who made the API
request (requires tracing through 2 frames at a minimum). The performance
loss may make the bug go away though, and so that should be considered.
--
Cheers,
Carlos.
- bug#43389: 28.0.50; Emacs memory leaks, (continued)
- bug#43389: 28.0.50; Emacs memory leaks, Eli Zaretskii, 2020/11/17
- bug#43389: 28.0.50; Emacs memory leaks, Carlos O'Donell, 2020/11/18
- bug#43389: 28.0.50; Emacs memory leaks, Jean Louis, 2020/11/18
- bug#43389: 28.0.50; Emacs memory leaks, Andreas Schwab, 2020/11/18
- bug#43389: 28.0.50; Emacs memory leaks, Jean Louis, 2020/11/18
- bug#43389: 28.0.50; Emacs memory leaks, Russell Adams, 2020/11/18
- 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 <=
- 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, 2020/11/19
- 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