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

Previous Next

Full log

Message #485 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>, Trevor Bentley <trevor <at> trevorbentley.com>
Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, michael_heerdegen <at> web.de,
 dj <at> redhat.com, bugs <at> gnu.support
Subject: Re: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Wed, 25 Nov 2020 12:48:20 -0500

On 11/24/20 2:35 PM, Eli Zaretskii wrote:
>> From: Trevor Bentley <trevor <at> trevorbentley.com>
>> Cc: bugs <at> gnu.support, fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org,
>>  dj <at> redhat.com, michael_heerdegen <at> web.de, carlos <at> redhat.com
>> Cc: 
>> Date: Tue, 24 Nov 2020 20:05:15 +0100
>>
>> I just updated the log on my website.  Same instance a day later, 
>> after yet another memory spike up to 4.3GB.  Concatenated to the 
>> end:
>>
>> https://trevorbentley.com/emacs_malloc_info.log
> 
> I don't think I can interpret that.  In particular, how come "total"
> is 4GB, but I see no comparable sizes in any of the other fields?
> where do those 4GB hide?  Carlos, can you help interpreting this
> report?

The 4GiB are in use by the application and it is up to us to increase
the observability of that usage with our tooling.

>> Question 3: I've never used the malloc_trim() function.  Could 
>> that be something worth experimenting with, to see if it releases 
>> any of the massive heap back to the OS?
> 
> That's for glibc guys to answer.

If malloc_info() shows memory that is free'd and unused then malloc_trim()
can free back any unused pages to the OS.

However, in your last day malloc_info() output you only show ~50MiB of
unused memory out of ~4GiB, so calling malloc_trim() would only free
~50MiB. There is heavy usage of the kernel heap by something. Finding
out what is using that memory is our next step.

-- 
Cheers,
Carlos.

Previous Next

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