bug#43389: 28.0.50; Emacs memory leaks using hard disk all time

[Carlos O'Donell <carlos@redhat.com>]

On 11/24/20 2:35 PM, Eli Zaretskii wrote:
>> From: Trevor Bentley <trevor@trevorbentley.com>
>> Cc: bugs@gnu.support, fweimer@redhat.com, 43389@debbugs.gnu.org,
>>  dj@redhat.com, michael_heerdegen@web.de, carlos@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.