GNU bug report logs - #43389
28.0.50; Emacs memory leaks

Previous Next

Full log

View this message in rfc822 format

From: Carlos O'Donell <carlos <at> redhat.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Florian Weimer <fweimer <at> redhat.com>
Cc: 43389 <at> debbugs.gnu.org, dj <at> redhat.com
Subject: bug#43389: 28.0.50; Emacs memory leaks
Date: Wed, 18 Nov 2020 00:43:55 -0500

On 11/17/20 4:10 PM, Eli Zaretskii wrote:
>> From: Florian Weimer <fweimer <at> redhat.com>
>> Cc: dj <at> redhat.com,  carlos <at> redhat.com,  43389 <at> 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.

-- 
Cheers,
Carlos.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.