Subject: Re: bug#43389: 28.0.50; Emacs memory leaks

From: Eli Zaretskii <[email-masked]>
Date: Tue, 17 Nov 2020 21:52:34 +0200

> From: DJ Delorie <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked]
> Date: Tue, 17 Nov 2020 12:20:21 -0500
> 
> Eli Zaretskii <[email-masked]> 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?