Emacs consuming CPU in end-less loop: what are my options?

Hi, On my old notebook I get this frequently (maybe a config issue), on my main machine (Emacs v26.3) I do have this behavior right now: After undoing a large deletion (during a bisect-task) GNU Emacs is consuming its one CPU core for 100%, not ending for an hour or so. I consider this an end-less loop. Emacs server is running as well. What are my options to debug what's going on? Can I somehow connect to the running instance and activate a profiler? Is there anything else besides killing the task what I can do? Thanks! **Update 2022-04-25T16.21 CET: C-g did not do anything.**

If it is an endless loop, C-g should stop it. Otherwise, you can send SIGUSR2 to emacs. It SIGUSR2 does not help as well, the issue is either related to core parts of emacs (e.g. garbage collecting) or its asynchronous code (e.g. font-lock).

pkill -SIGUSR2 -i emacs

Note that if you are able to predict the issue, executing `M-x toggle-debug-on-quit` before it occurs will make `C-g` break into the debugger with a stack trace showing you what code was executing.

Sorry, I forgot to mention that C-g did not stop the loop. Furthermore, when switching to a different window and coming back to Emacs, window redraw did not work either, resulting in an empty window (as displayed on my desktop).

If it’s stuck like that, it’s probably inflooping in C code and signals have been blocked. The only way to “see” where it’s stuck is with a debugger, but your emacs probably doesn’t have debug symbols. So, unless you’re experienced in debugging assembly language without source code (and you’re likely not since you’re asking this question, no offense), there’s probably nothing that you can do. However, you’re using an old emacs. Maybe upgrade to 27.2 and hope that the problem has been fixed? (Yes, 28.1 is the latest, but I don’t know how well it’ll run on older systems since most precompiled binaries likely have JIT compiling enabled.)

I thought so - just wanted to get confirmation that I can only kill the task. Will try the SIGUSR2 signal next time. Yes, I do have an old Emacs because that's the version that comes with my Xubuntu 20.04 LTS which will be soon upgraded to Xubuntu 22.04 LTS with a newer Emacs. So far, I never had the urge to switch to a non-distribution Emacs package (or had bad experience with it). Thanks for the confirmation!

> most precompiled binaries likely have JIT compiling enabled I hope not. It's a non-default feature which will cause lots of system slow-downs when people start using it, which will be highly unexpected for anyone not already in-the-know (which I think will include the majority of people using Emacs via an OS package). (This is not just a speculative concern either -- I've already read of one case of such an OS package bringing a user's underpowered laptop to its knees, and making Emacs completely unusable. I've also personally experienced this feature consistently slowing my Emacs start time by an order of magnitude, on account of the anti-virus software on a work machine. It's a feature which comes at some significant costs.) IMO anyone packaging 28.1 as a straight upgrade of an earlier OS package should definitely *not* be building `--with-native-compilation` but rather provide that in an optional alternative package for the users who know what they are asking for and wish to opt-in.

SIGUSR2 generally helps with most of Elisp-level code. At least, you should see the frame name changing to *Backtrace*. If you do see such change, I would suspect font-locking. Otherwise, something more low-level. Also, large deletions might cause hangs if you are using undo-tree.

Most of the issues with native compilation during startup are only happening until Emacs compiles all the loaded external libraries - it is an one-off thing. Also, you can always disable native compilation by setting native-comp-deferred-compilation-deny-list to `'(".*")`

I'm not disputing any of that; I'm just saying these things shouldn't be foisted upon anyone unexpectedly.

I understand your frustration. However, the right place to discuss this would be emacs-devel. Otherwise, your complaints will not serve any constructive purpose.

It's an issue for OS package maintainers, not for emacs-devel. The Emacs maintainers have *already* done the right thing by making it an opt-in feature. I'm just saying that OS package maintainers should refrain from opting in for their standard package. (I would encourage them to opt-in for a new alternative package.)

Attach a debugger and produce a C-level backtrace. Crystal ball says you will see Emacs performing GC, and it also says that you have too little VM configured, so touching a lot of memory makes the system thrash. Maybe you also increased the GC threshold, per some unwise advice on the net, and that makes your GC cycles even more violent.

You could install [Nix](https://nixos.org/download.html#download-nix) or [Guix](https://guix.gnu.org/manual/en/html_node/Binary-Installation.html) as an additional package manager if you want to give a newer version of Emacs a go before upgrading your system. With Guix you might want to add [this channel](https://github.com/flatwhatson/guix-channel) (for native compilation).

Thanks for the idea. However, I had pretty bad experience with mixing up different package managers and breaking dependencies because of that (Debian not knowing about Nix packages and vice versa).

I just had another incident where Emacs 26.3 did end up in an endless loop while saving a buffer. Remembering this thread I applied: `pkill -SIGUSR2 -i emacs` And yes, it worked in this instance, showing me this output: [https://paste.grml.org/hidden/763d8be2/](https://paste.grml.org/hidden/763d8be2/) The issue was reproducible. As long as I had the following line in the buffer, saving ended up in an endless loop: | pi@co2lampel2 ~ % mqtt-receive.py -o 192.168.2.2 This was a line I copied from an external source. I realized that it might confuse Org-mode because it has a pipe symbol at its front that is used in Org tables. Then I changed it to: : pi@co2lampel2 ~ % mqtt-receive.py -o 192.168.2.2 ... and saving the buffer worked. Weird.

I recall something similar. Are you using the latest Org? Not the version you downloaded from my github months ago?

Currently, I'm still working with `url =` [`https://git.savannah.gnu.org/git/emacs/org-mode.git`](https://git.savannah.gnu.org/git/emacs/org-mode.git) but maybe I should switch to a different repo. Honestly, I lost overview what I should use to get decent performance without living on the edge, getting all kinds of side effects from bleeding edge situations. What is your recommendation to me?

Your repo is the right repo (assuming that you are using main branch). It is also listed in https://orgmode.org/. > Honestly, I lost overview what I should use to get decent performance without living on the edge, getting all kinds of side effects from bleeding edge situations. Unfortunately, the major performance optimisations are the beeding edge for now. It will only be stabilised with the next Org release (not soon - Org 9.5 was just out recently). However, I think I have fixed the infinite loops like your months ago (there were no bug reports in that area). So, you may just need to git fetch the latest main if you are not on it yet. In future, when you are satisfied with performance and do not see any issues, you may freeze your repo on specific commit and use it. Or update only when you do not have pending deadlines in sight.

I'm at the "main" branch, yes. However, the newest commit is from a couple of months ago: ``` 8d9ca0eac - (HEAD -> main) test-org/entry-get: Add test checking reported bug (4 months ago)<Ihor Radchenko> ``` So no news for me when pulling from that repo at the moment.

I am confused. Did you try to run git pull? Here is the latest log: https://git.savannah.gnu.org/cgit/emacs/org-mode.git/log (html version)

Shit, my bad: I didn't realize that my pull job was failing because of uncommitted changes. I usually never change and therefore, I had no error handling built-in for that task. Now I'm on ``` 2a6f5cecf - (HEAD -> main, origin/main, origin/HEAD) test-org: Add new test `test-org/org-find-olp' (22 hours ago)<Ihor Radchenko> ```