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:

I figure we should more or less ignore VSZ for something like this. Isn't it common in lisp programs to allocate a huge block of memory up front? Doesn't mean it's ever actually used, and it being Linux it's not taken from anything else just be allocation. The RSS is pretty big compared to what I remember, certainly big next to perl 5, but if anything it seems to be zippier, though that could be subjective.

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.

1 members found this post helpful.

The emacs upgrade was really a security patch against CVE-2022-45939.
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

1 members found this post helpful.

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.

1 members found this post helpful.

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.

1 members found this post helpful.

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.

1 members found this post helpful.

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.

1 members found this post helpful.

My emacs server crashes with this

But when launched as standalone and gui it works. Kinda : 15 seconds for 50 packages loaded...

1 members found this post helpful.

same here in when started as a daemon (even with X11)...

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...

1 members found this post helpful.

just recompiled with the athena (lucid) toolkit and indeed it doesn't crash in daemon mode anymore... hopefully this was the bug that was biting me... thanks for the hint!

1 members found this post helpful.

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...
When I had those and another active emacs (emacs --daemon but I'm guessing it wouldn't matter what kind) and I run emacs -nw I'd get this question on start up...
If I type 'y' I get an abort...
If I type 'n' it starts fine and I can run list-packages without an abort...
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:

This is all with Slackware 15.0, Emacs 29.3, Xorg, and a window manager only modestly changed from twm.

For what it's worth I compile Emacs 29.3 with a modified SlackBuild (including native compilation) on 15.0 (Plasma/X11), and I'm not seeing this crash, nor the memory leak issue.