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

Previous Next

Full log

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

From: Carlos O'Donell <carlos <at> redhat.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Jean Louis <bugs <at> gnu.support>
Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, trevor <at> trevorbentley.com,
 michael_heerdegen <at> web.de, dj <at> redhat.com
Subject: Re: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Sun, 22 Nov 2020 22:41:00 -0500

On 11/22/20 3:16 PM, Eli Zaretskii wrote:
>> Date: Sun, 22 Nov 2020 22:52:14 +0300
>> From: Jean Louis <bugs <at> gnu.support>
>> Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, dj <at> redhat.com,
>>   michael_heerdegen <at> web.de, trevor <at> trevorbentley.com, carlos <at> redhat.com
>>
>> I am now following this strategy here:
>> https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Leak-Checking
> 
> That uses a different implementation of malloc, so I'm not sure it
> will help us.

Correct, that is a different malloc implementation and may have
completely different behaviour for your given workload. That is
not to say that it isn't viable solution to try another allocator
that matches your workload. However, in this bug we're trying to
determine why the "default" configuration of emacs and glibc's
allocator causes memory usage to grow.

We want to run the glibc malloc algorithms because that is the
implementation under which we are observing the increased memory
pressure. The tracer I've suggested will get us an API trace
that we can use to determine if it is actually API calls that
are causing an increase in the memory usage or if it's an
algorithmic issue. It is not always obvious to see from the
API calls, but having the trace is better than not.

-- 
Cheers,
Carlos.

Previous Next

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