[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Arthur Miller
Subject: bug#43389: 28.0.50; Emacs memory leaks using hard disk all time
Date: Mon, 23 Nov 2020 22:12:12 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: bugs@gnu.support,  fweimer@redhat.com,  43389@debbugs.gnu.org,
>>   dj@redhat.com,  michael_heerdegen@web.de,  trevor@trevorbentley.com,
>>   carlos@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.

Attachment: em-heaptrack1.png
Description: PNG image

Attachment: em-heaptrack2.png
Description: PNG image

Attachment: em-heaptrack3.png
Description: PNG image

Attachment: em-heaptrack4.png
Description: PNG image

Attachment: em-heaptrack5.png
Description: PNG image

Attachment: heaptrack.emacs.52042.zst
Description: application/zstd

reply via email to

[Prev in Thread] Current Thread [Next in Thread]