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

Previous Next

Full log

View this message in rfc822 format

From: Carlos O'Donell <carlos <at> redhat.com>
To: 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 Bentley <trevor <at> trevorbentley.com>, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Wed, 25 Nov 2020 14:01:32 -0500

On 11/25/20 1:08 PM, Jean Louis wrote:
> * Carlos O'Donell <carlos <at> redhat.com> [2020-11-25 20:45]:
>> With glibc-malloc-trace-utils you can try to do that with:
>>
>> LD_PRELOAD=libmtrace.so \
>> MTRACE_CTL_FILE=/home/user/app.mtr \
>> MTRACE_CTL_BACKTRACE=1 \
>> ./app
>>
>> 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.
> 
> 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?

It could. If there are timing sensitivities to this issue then it might
be sufficiently perturbed that it doesn't reproduce. The above backtracing
is expensive and increases the performance impact. However, given that
we want to know who the caller was and determine the source of the 4.2GiB
allocations... we need to try capture that information.

-- 
Cheers,
Carlos.

Previous Next

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