bug#43389: 28.0.50; Emacs memory leaks

[Eli Zaretskii]

> From: DJ Delorie <dj@redhat.com>
> Cc: carlos@redhat.com, fweimer@redhat.com, 43389@debbugs.gnu.org
> Date: Tue, 17 Nov 2020 12:20:21 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > You mean, trace all the memory allocations in Emacs with the tracer?
> > That would produce huge amounts of data, as Emacs calls malloc at an
> > insane frequency.  Or maybe I don't understand what kind of tracing
> > procedure you had in mind
> 
> That's exactly what it does, and yes, it easily generates gigabytes
> (sometimes terabytes) of trace information.  But it also captures the
> most accurate view of what's going on, and lets us replay (via
> simulation) all the malloc API calls, so we can reproduce most
> malloc-related problems on a whim.

Is it possible to start tracing only when the fast growth of memory
footprint commences?  Or is tracing from the very beginning a
necessity for providing meaningful data?