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

Previous Next

Full log

View this message in rfc822 format

From: Arthur Miller <arthur.miller <at> live.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, bugs <at> gnu.support, dj <at> redhat.com, michael_heerdegen <at> web.de, trevor <at> trevorbentley.com, carlos <at> redhat.com
Subject: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Mon, 23 Nov 2020 22:12:12 +0100

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Arthur Miller <arthur.miller <at> live.com>
>> Cc: bugs <at> gnu.support,  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
>> Date: Mon, 23 Nov 2020 20:49:48 +0100
>> 
>> Isn't Valgrind good for this kind of problems? Can I run emacs as a
>> systemd service in Valgrind?
>
> You can run Emacs under Valgrind, see etc/DEBUG for the details.  But
> I'm not sure it will work as systemd service.
>
> Valgrind is only the right tool if we think there's a memory leak in
> Emacs itself.
Ok, I'll take a look at debug docs; It's ok, just i get a test I can run
it as normal process; it's ok.

Anyway I have tested heaptrack; It built in like few seconds, nothing
special there.

I am not sure about the tool; I think it missunderstands memory taken by
lisp environement as a leaked memory. It repports like heap loads of
leaks :-), so it must be that it just missunderstands Emacs. I am not
sure, I am attaching few screenshots, but I don't believe it can be that
many leaks as it rapports. It is just emacs what one gets from emacs -Q
there. I will attach the generated data too.

I had some problem with it too. I tried to attach it to a running deamon
process (started by sysd) and it failed untill I run it as sudo
user. As soon as it attached itself seems that both server and
emacsclient got completely unresponsive and stayed that way. I killed
client process, but windowed stayed alive, I had to kill it with
xkill. After I restarded server Emacs didn't read the init file, because
paths got messed up, so I had to sort that out too. Also the tool
produced empty rapport (it didn't work). But runnign on standalone emacs
process as a sudo user worked.

Anyway, despite problems it seems to be very nice graphical tool to see
call stack and how Emacs looks like internally; but I am not sure if it
works at all to find leaks in Emacs.

[em-heaptrack1.png (image/png, attachment)]

[em-heaptrack2.png (image/png, attachment)]

[em-heaptrack3.png (image/png, attachment)]

[em-heaptrack4.png (image/png, attachment)]

[em-heaptrack5.png (image/png, attachment)]

[heaptrack.emacs.52042.zst (application/zstd, attachment)]

Previous Next

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