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

Previous Next

Full log

Message #206 received at 43389 <at> debbugs.gnu.org (full text, mbox):

From: Florian Weimer <fweimer <at> redhat.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: carlos <at> redhat.com, 43389 <at> debbugs.gnu.org, dj <at> redhat.com
Subject: Re: bug#43389: 28.0.50; Emacs memory leaks
Date: Tue, 17 Nov 2020 21:58:57 +0100

* Eli Zaretskii:

>> From: Florian Weimer <fweimer <at> redhat.com>
>> Cc: DJ Delorie <dj <at> redhat.com>,  carlos <at> redhat.com,  43389 <at> debbugs.gnu.org
>> Date: Tue, 17 Nov 2020 21:35:54 +0100
>> 
>> * Eli Zaretskii:
>> 
>> > (It would be interesting to see the GC statistics from Florian's
>> > session, btw.)
>> 
>> Is this the value of (garbage-collect)?
>> 
>> ((conses 16 1877807 263442)
>>  (symbols 48 40153 113)
>>  (strings 32 164110 77752)
>>  (string-bytes 1 5874689)
>>  (vectors 16 64666)
>>  (vector-slots 8 1737780 331974)
>>  (floats 8 568 1115)
>>  (intervals 56 163746 19749)
>>  (buffers 1000 1092))
>
> Yes.  "C-h f garbage-collect" will describe the meaning of the
> numbers.  AFAICT, this barely explains 70 MBytes and change of Lisp
> data.  (The "buffers" part excludes buffer text, but you should be
> able to add that by summing the sizes shown by "C-x C-b".)

I get this:

(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.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

Previous Next

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