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

Previous Next

Full log

View this message in rfc822 format

From: Trevor Bentley <trevor <at> trevorbentley.com>
To: Jean Louis <bugs <at> gnu.support>, Carlos O'Donell <carlos <at> redhat.com>
Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, michael_heerdegen <at> web.de, dj <at> redhat.com
Subject: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Wed, 25 Nov 2020 19:51:39 +0100

Jean Louis <bugs <at> gnu.support> writes:

>> This will use libgcc's unwinder to get a copy of the malloc 
>> caller address and then we'll have to decode that based on a 
>> /proc/self/maps. 
> 
> I will also try that in the next session. 

As will I, but probably won't set it up until this weekend.

> One problem I have here is that since I run this session I have 
> not get any problem. My uptime is over 2 days, I have not 
> changed my habbits of work within Emacs and my swap remains 
> under 200 MB and only 10% memory used by Emacs, normally 80-90% 
> 
> Almost by the rule I could not run longer than 1 day until I 
> would get swap of about 3 GB - 4 GB and not responsive Emacs. 
> 
> Can it be that libmtrace.so could prevent something happening 
> what is normally happening? 

I see high variation in how long it takes to hit it on my machine. 
The shortest was after ~4 hours, average is 1.5 days, and the 
longest was 5 days.  Perhaps you're seeing the same.

I also still hit it while running under Valgrind; the whole emacs 
session was slow as hell, but still managed to blow out its heap 
in a few days.  Of course, libmtrace could be different, but at 
least it doesn't seem to be a heisenbug.

-Trevor

Previous Next

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