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

Previous Next

Package: emacs;

Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>

Date: Mon, 14 Sep 2020 00:44:01 UTC

Severity: normal

Merged with 43395, 43876, 44666

Found in version 28.0.50

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log

View this message in rfc822 format

From: Carlos O'Donell <carlos <at> redhat.com>
To: Trevor Bentley <trevor <at> trevorbentley.com>, Jean Louis <bugs <at> gnu.support>
Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, michael_heerdegen <at> web.de, dj <at> redhat.com
Subject: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Wed, 25 Nov 2020 15:51:16 -0500

On 11/25/20 2:17 PM, Trevor Bentley wrote:
> Carlos O'Donell <carlos <at> redhat.com> writes:
> 
>> On 11/25/20 1:51 PM, Trevor Bentley wrote:
>>> I also still hit it while running under Valgrind; the whole emacs session was slow as hell, but still managed to blow out its heap in a few days.  Of course, libmtrace could be different, but at least it doesn't seem to be a heisenbug. 
>>
>> Do you have a valgrind report to share? 
> 
> Yes, they were earlier in this bug report, perhaps before you joined.  It was the 'massif' heap tracing tool from the valgrind suite, not the regular valgrind leak detector.
> 
> Here are the links again:
> 
>  The raw massif output:
>  http://trevorbentley.com/massif.out.3364630
>  The *full* tree output:
>  http://trevorbentley.com/ms_print.3364630.txt
>  The tree output showing only entries above 10% usage:
>  http://trevorbentley.com/ms_print.thresh10.3364630.txt

This data is pretty clear:

 1.40GiB - lisp_align_malloc (alloc.c:1195)
 1.40GiB - lmalloc (alloc.c:1359)
 0.65GiB - lrealloc (alloc.c:1374)
 0.24GiB - AcquireAlignedMemory (/usr/lib/libMagickCore-7.Q16HDRI.so.7.0.0)
--------
 3.60Gib - In use as of the snapshot.

That's a fairly high fraction of the ~4.2GiB that is eventually in use.

With lisp_align_malloc, lmalloc, and lrealloc shooting up exponentially at the end of the run look like they are making lists and processing numbers and other objects.

This is a direct expression of something increasing demand for memory.
	
-- 
Cheers,
Carlos.
This bug report was last modified 4 years and 58 days ago.

Previous Next

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