[Top][All Lists]

[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: Wed, 18 Nov 2020 00:43:55 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

On 11/17/20 4:10 PM, Eli Zaretskii wrote:
>> From: Florian Weimer <fweimer@redhat.com>
>> Cc: dj@redhat.com,  carlos@redhat.com,  43389@debbugs.gnu.org
>> Date: Tue, 17 Nov 2020 21:58:57 +0100
>> (let ((size 0))
>>   (dolist (buffer (buffer-list) size)
>>     (setq size (+ size (buffer-size buffer)))))
>> ⇒ 98249826
>> So it's not a small number, but still far away from those 800 MiB.
> Yes.  I have a very similar value: 94642916 (in 376 buffers; you have
> more than 1000).  This is in a session that runs for 17 days and whose
> VM size is 615 MB: a "normal" size for a long-living session, nowhere
> near 2GB, let alone 11GB someone reported.

If you get us a data trace I will run it through the simulator and produce
a report that includes graphs explaining the results of the trace and
we'll see if a smoking gun shows up.

The biggest smoking gun is a spike in RSS size without a matching Ideal
RSS (integral of API calls). This would indicate an algorithmic issue.

Usually though we can have ratcheting effects due to mixed object
liftimes and those are harder to detect and we don't have tooling for
that to look for such issues. We'd need to track chunk lifetimes.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]