emacs leaks memory after upgrade to 29.3
Hi,
after the latest upgrade of Emacs in Slackware64 15.0, some stuff was broken so I did M-x package-upgrade-all, and after that everything seemed to work just fine. But today I noticed my system becoming slow whenever I ran emacs, and sure, it takes a full virtual CPU core (shows at 12.3% CPU untilisation) and eats RAM like there's no tomorrow. I've seen it stop growing at 5.5 GB or even go up above 8. Is there a way to debug this, see what inside emacs is doing this? |
When started with -Q, so no customizations whatsoever, RAM utilisation rises slower, but the constant CPU utilisation still happens.
|
went back to the old version for now.
emacs-27.2-x86_64-2_slack15.0.txz from https://slackware.uk/cumulative/slac...ches/packages/ |
I'm not seeing this so far. Haven't loaded a whole bunch of files, but with eww visiting slackware.com, a small common lisp file, and slime running, this is my memory usage:
Code:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND I was pretty happy to get this update in 15.0, so I hope the memory leak you see isn't universal. I feel like my operating system has gotten a major upgrade, like an early birthday present, more so than I would with a new kernel or glibc, and I don't use a window manager that changes with upgrades. It's so cool how Slackware will upgrade instead of patch when it makes sense to. |
Quote:
It might be OK to stick with older versions of emacs as long as ctags is not used in directories with untrusted contents. regards Henrik |
I should add that I run a Wayland Plasma session, maybe that plays into it, considering the other thread where there's problems with Emacs/X interplay (iirc).
|
I've been having to build emacs by hand from its git sources, or it was crashing when in emacs orgmode; don't know if that crash is related to your observed ram consumption and increased cpu; but just chiming in that I was having to replace the stock package in my slackware64-15 use cases.
|
I experienced this issue too, and it froze my machine with 8GB of RAM multiple times. I had to power it off.
I too had some packages installed: magit, js2-mode, git-gutter, projectile, php-mode. I was using Plasma on X11, not Wayland. |
8GB of RAM and 8GB of swap. It filled both of them.
I know because I was running a system monitor on a SSH session. |
By the way, Emacs 29.3 has other problems. Some commands crash Emacs with a backtrace when in text mode (emacs -nw). For example M-x list-packages.
|
My emacs server crashes with this
Code:
Warning: due to a long standing Gtk+ bug |
Quote:
actually the same occasionally happened also with emacs-27 when exiting the server buffer in gnus... quite annoying: lately emacs is becoming quite unstable. what a pity... |
Quote:
|
I've seen that warning about gtk a lot, on Slackware and on Ubuntu at work, but don't recall an abort while I was actively using emacsclient and daemon. I do notice emacs core files sometimes (on NetBSD I think and maybe not on Slackware), so I'm guessing I get an abort when shutting down X without stopping the emacs daemon (with some version of emacs).
So far I've gotten the abort with the thread list two ways. One was before removing these two customizations... Quote:
Quote:
Quote:
Warning: desktop file appears to be in use by PID 1449. Using it may cause conflicts. Use it anyway? (y or n) n Desktop file in use; not loaded. For information about GNU Emacs and the GNU system, type C-h C-a. Importing package-keyring.gpg...done Package refresh done The 2nd way was that earlier I had an invalid emacs package url. Shortly after the error about that popped up it would abort if started as emacs -nw (that test was as a 2nd emacs instance two and pressing 'n' for the desktop question IIRC). I no longer get an abort with desktop mode off and with the bad url removed, though I did see an error message about an invalid file descripter flash by when running list-packages. It may have only been written to stderr (or stdout?). I'm not seeing it in .xsession-errors or in emacs's message buffer. I've made a note to try to debug this sometime, er maybe. I continue to see relatively moderate memory usage and no performance problems when emacs does not abort, and it doesn't at all in my normal usage, but I don't care for console only emacs and don't use it much: Quote:
|
Quote:
|
All times are GMT -5. The time now is 04:38 PM. |