bug#43389: 28.0.50; Emacs memory leaks using hard disk all time

[Eli Zaretskii]

> Cc: trevor@trevorbentley.com, bugs@gnu.support, fweimer@redhat.com,
>  43389@debbugs.gnu.org, dj@redhat.com, michael_heerdegen@web.de
> From: Carlos O'Donell <carlos@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...