Eli Zaretskii writes: >> From: Arthur Miller >> 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.