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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Carlos O'Donell <carlos <at> redhat.com>
Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, bugs <at> gnu.support, dj <at> redhat.com, michael_heerdegen <at> web.de, trevor <at> trevorbentley.com
Subject: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Thu, 26 Nov 2020 22:30:14 +0200

> Cc: trevor <at> trevorbentley.com, bugs <at> gnu.support, fweimer <at> redhat.com,
>  43389 <at> debbugs.gnu.org, dj <at> redhat.com, michael_heerdegen <at> web.de
> From: Carlos O'Donell <carlos <at> redhat.com>
> Date: Thu, 26 Nov 2020 15:21:04 -0500
> 
> On 11/26/20 8:58 AM, Eli Zaretskii wrote:
> > Apart of that, I think we really need to see the most significant
> > customers of these functions when the memory footprint starts growing
> > fast.
>  
> It's in the mastiff captured data.
> 
> Of the 1.7GiB it's all in Fcons:
> 
> 448.2 MiB: Fmake_list
> 270.3 MiB: in 262 places all over the place (below massif's threshold)
> 704.0 MiB: list4 -> exec_byte_code
> 109.7 MiB: F*_json_read_string_0 -> funcall_subr ...
> 102.2 MiB: Flist -> exec_byte_code ...
>  68.5 MiB: Fcopy_alist -> Fframe_parameters ...

Thanks.  Those are the low-level primitives, they tell nothing about
the Lisp code which caused this much memory allocation.  We need
higher levels of callstack, and preferably in Lisp terms.  GDB
backtraces would show them, due to tailoring in src/.gdbinit.

Previous Next

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