SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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?
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
XXXXXX 16175 1.4 4.0 805388 158012 ? Ssl 21:28 0:56 emacs --daemon
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.
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.
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.
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.
Warning: due to a long standing Gtk+ bug
https://gitlab.gnome.org/GNOME/gtk/issues/221
Emacs might crash when run in daemon mode and the X11 connection is unexpectedly lost.
Using an Emacs configured with --with-x-toolkit=lucid does not have this problem.
Loading ~/.config/emacs/custom.el (source)...
Importing package-keyring.gpg...
emacs: writing to child signal FD: Bad file descriptor
Backtrace:
emacs[0x577bf3]
emacs[0x425b3e]
emacs[0x4260b3]
emacs[0x42ae75]
emacs[0x62e5b4]
emacs[0x61ef61]
emacs[0x5de79b]
emacs[0x5dd243]
emacs[0x5dd7dd]
emacs[0x5dd551]
emacs[0x60b5ba]
emacs[0x60c7a1]
emacs[0x61ef61]
emacs[0x5d9867]
emacs[0x60c420]
emacs[0x5dd4d5]
emacs[0x5dd7dd]
emacs[0x5dd551]
emacs[0x5dd551]
emacs[0x60b5ba]
emacs[0x60c7a1]
emacs[0x61ef61]
emacs[0x5d9867]
emacs[0x60c420]
emacs[0x61ef61]
emacs[0x5de79b]
emacs[0x5dd243]
emacs[0x5df69a]
emacs[0x5d813f]
emacs[0x55696d]
emacs[0x5d80a3]
emacs[0x555f03]
emacs[0x55a80c]
emacs[0x55ab77]
emacs[0x42e038]
/lib64/libc.so.6(__libc_start_main+0xcd)[0x7f5c992b603d]
emacs[0x42e5ba]
Error: server did not start correctly
But when launched as standalone and gui it works. Kinda : 15 seconds for 50 packages loaded...
Last edited by Tonus; 04-08-2024 at 03:05 PM.
Reason: Get the error in english
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.
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...
Warning: due to a long standing Gtk+ bug
https://gitlab.gnome.org/GNOME/gtk/issues/221
Emacs might crash when run in daemon mode and the X11 connection is unexpectedly lost.
Using an Emacs configured with --with-x-toolkit=lucid does not have this problem.
...
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!
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...
Quote:
Warning: desktop file appears to be in use by PID 1449.
Using it may cause conflicts. Use it anyway? (y or n)
If I type 'y' I get an abort...
Quote:
1016r0~% emacs -nw
Fatal error 6: Aborted
Backtrace:
emacs[0x577bf3]
emacs[0x425b3e]
emacs[0x4260b3]
emacs[0x42ae75]
emacs[0x438ba6]
...
emacs[0x42e038]
/lib64/libc.so.6(__libc_start_main+0xcd)[0x7f91ce4e203d]
... [that's verbatim, the early one is me leaving out threads]
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:
Quote:
984r0~% pgrep -al emacs
1471 emacs
6344 emacs -nw
6424 emacs --daemon
6427 emacsclient -c -F ((width . 92) (height . 38) (top . -25) (left . 220))
6446 emacs --nw
986r1~% sh
sh-5.1$ for p in 1471 6344 6424 6427 6446; do ps u $p; done
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
smallm 1471 0.0 0.0 0 0 ? Z 20:16 0:00 [emacs] <defunc
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
smallm 6344 0.9 3.1 589100 121732 pts/0 Tl 23:22 0:12 emacs -nw
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
smallm 6424 1.4 3.3 763384 128636 ? Ssl 23:31 0:10 emacs --daemon
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
smallm 6427 0.0 0.0 2464 740 ? S 23:31 0:00 emacsclient -c
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
This is all with Slackware 15.0, Emacs 29.3, Xorg, and a window manager only modestly changed from twm.
Last edited by thirdm; 04-10-2024 at 10:56 PM.
Reason: weird sentence
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.