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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Trevor Bentley <trevor <at> trevorbentley.com>
Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, bugs <at> gnu.support, dj <at> redhat.com,
 carlos <at> redhat.com, michael_heerdegen <at> web.de
Subject: Re: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Tue, 24 Nov 2020 18:07:52 +0200

> From: Trevor Bentley <trevor <at> trevorbentley.com>
> Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, dj <at> redhat.com,
>  michael_heerdegen <at> web.de, carlos <at> redhat.com
> Cc: 
> Date: Mon, 23 Nov 2020 22:30:57 +0100
> 
> ;;--------------------------------------
> ;;--------------------------------------
> ;; 3 days later
> ;; RSS was steady at 1150MB
> ;; leaped to 2.3GB very suddenly
> ;;
> ;; RSS 2311M
> ;;--------------------------------------
> ;;--------------------------------------

> ;; ~182MB
> (let ((size 0))
>   (dolist (buffer (buffer-list) size)
>     (setq size (+ size (buffer-size buffer)))))
> 182903045
> 
> ;; sums to ~142MB if I'm reading it right?
> (garbage-collect)
> ((conses 16 2081486 2630206) (symbols 48 61019 79) (strings 32 353371 288980) (string-bytes 1 13294206) (vectors 16 144742) (vector-slots 8 9503757 592939) (floats 8 2373 8320) (intervals 56 46660 10912) (buffers 992 82))

> (reduce '+ (cl-loop for thing in (garbage-collect)
>                     collect (* (nth 1 thing) (nth 2 thing))))
> 142115406
> 
> ;; malloc-info
> (malloc-info)
> <malloc version="1">
> <heap nr="0">
> <sizes>
>   <size from="33" to="48" total="240" count="5"/>
>   <size from="113" to="128" total="128" count="1"/>
> [...]
>   <size from="3137" to="3569" total="2372709" count="709"/>
>   <size from="3585" to="4081" total="1847856" count="480"/>
>   <size from="4097" to="4593" total="5672856" count="1320"/>
>   <size from="4609" to="5105" total="4675836" count="956"/>
>   <size from="5121" to="5617" total="6883318" count="1286"/>
>   <size from="5633" to="6129" total="6011919" count="1023"/>
>   <size from="6145" to="6641" total="6239871" count="975"/>
>   <size from="6657" to="7153" total="6540165" count="949"/>
>   <size from="7169" to="7665" total="5515848" count="744"/>
>   <size from="7681" to="8177" total="5148216" count="648"/>
>   <size from="8193" to="8689" total="8190223" count="975"/>
>   <size from="8705" to="9201" total="5854315" count="651"/>
>   <size from="9217" to="9713" total="5312354" count="562"/>
>   <size from="9729" to="10225" total="5154212" count="516"/>
>   <size from="10241" to="10737" total="4074005" count="389"/>
>   <size from="10753" to="12273" total="11387550" count="990"/>
>   <size from="12289" to="16369" total="32661229" count="2317"/>
>   <size from="16385" to="20465" total="36652437" count="2037"/>
>   <size from="20481" to="24561" total="21272131" count="947"/>
>   <size from="24577" to="28657" total="25462302" count="958"/>
>   <size from="28673" to="32753" total="28087234" count="914"/>
>   <size from="32769" to="36849" total="39080113" count="1121"/>
>   <size from="36865" to="40945" total="30141527" count="775"/>
>   <size from="40961" to="65521" total="166092799" count="3119"/>
>   <size from="65537" to="98289" total="218425380" count="2692"/>
>   <size from="98321" to="131057" total="178383171" count="1555"/>
>   <size from="131089" to="163825" total="167800886" count="1142"/>
>   <size from="163841" to="262065" total="367649915" count="1819"/>
>   <size from="262161" to="522673" total="185347984" count="560"/>
>   <size from="525729" to="30878897" total="113322865" count="97"/>

Look at the large chunks in the tail of this.  Together, they do
account for ~2GB.

Carlos, are these chunks in use (i.e. allocated and not freed), or are
they the free chunks that are available for allocation, but not
released to the OS?  If the former, then it sounds like this session
does have around 2GB of allocated heap data, so either there's some
allocated memory we don't account for, or there is indeed a memory
leak in Emacs.  If these are the free chunks, then the way glibc
manages free'd memory is indeed an issue.

Previous Next

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