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: 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.