GNU bug report logs - #43389
28.0.50; Emacs memory leaks

Previous Next

Full log

Message #260 received at 43389 <at> debbugs.gnu.org (full text, mbox):

From: Carlos O'Donell <carlos <at> redhat.com>
To: DJ Delorie <dj <at> redhat.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org
Subject: Re: bug#43389: 28.0.50; Emacs memory leaks
Date: Thu, 19 Nov 2020 11:08:56 -0500

On 11/18/20 1:27 PM, DJ Delorie wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>> If you asked Florian, then I agree that his data could be useful.  If
>> you were asking me, then my data is not useful, because the footprint
>> is reasonable and never goes up to gigabyte range.
> 
> Yeah, the hard part here is capturing the actual problem.  I'm running
> the latest Emacs too but haven't seen the growth.  Traces tend to be
> more useful when the problem is reproducible in situ but really hard to
> reproduce in a test environment.

My commitment is this: If anyone can reproduce the problem with the tracer
enabled then I will analyze the trace and produce a report for the person
submitting the trace.

The report will include some graphs, and an analysis of the API calls and
the resulting RSS usage.

I've written several of these reports, but so far they haven't been all
that satisfying to read. We rarely find an easily discoverable root cause.

We probably need better information on the exact lifetimes of the the
allocations.

For example I recently added a "caller" frame trace which uses the dwarf
unwinder to find the caller and record that data. It's expensive and on
only if requested. This is often useful in determining who made the API
request (requires tracing through 2 frames at a minimum). The performance
loss may make the bug go away though, and so that should be considered.

-- 
Cheers,
Carlos.

Previous Next

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