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: Fri, 27 Nov 2020 09:40:53 +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: Fri, 27 Nov 2020 00:04:56 -0500
> 
> >> 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.
> 
> Sure, let me pick one for you:
> 
> lisp_align_malloc (alloc.c:1195)
>  Fcons (alloc.c:2694)
>   concat (fns.c:730)
>    Fcopy_sequence (fns.c:598)
>     timer_check (keyboard.c:4395)
>      wait_reading_process_output (process.c:5334)
>       sit_for (dispnew.c:6056)
>        read_char (keyboard.c:2742)
>         read_key_sequence (keyboard.c:9551)
>          command_loop_1 (keyboard.c:1354)
>           internal_condition_case (eval.c:1365)
>            command_loop_2 (keyboard.c:1095)
>             internal_catch (eval.c:1126)
>              command_loop (keyboard.c:1074)
>               recursive_edit_1 (keyboard.c:718)
>                Frecursive_edit (keyboard.c:790)
>                 main (emacs.c:2080)
>  
> There is a 171MiB's worth of allocations in that path.
> 
> There are a lot of traces ending in wait_reading_process_output that
> are consuming 50MiB.

Thanks.  If they are like the one above, the allocations are due to
some timer.  Could be jabber, I'll take a look at it.  Or maybe
helm-ff--cache-mode-refresh, whatever that is; need to look at Helm as
well.

However, GDB's backtraces are even more informative, as they show Lisp
functions invoked in-between (via exec_byte_code, funcall_subr, etc.).
These pinpoint the offending Lisp code much more accurately.  The
downside is that running with GDB stopping Emacs and emitting the
backtrace is no fun...

Previous Next

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