Is there a trick to debugging a spin in emacs elisp, in a flymake module?

Question

I am getting a CPU spin in emacs elisp, within the C# flymake module. (Flymake is the module in emacs that periodically runs a build, then highlights any syntax errors or warnings in the current buffer.)

I'm about to wade into the code, to look for likely spots where a spin could occur.

While I'm at it, does anyone have suggestions for figuring out the spin? Is there something in emacs that allows me to stop execution and see where it stopped?

Answer 1

Use M-x set-variable to set debug-on-quit to t. Then when the problem happens, hit C-g and the debugger will give you a backtrace of what was running when you stopped it.

Answer 2

Flymake sets a 1-second timer for each buffer that has flymake-mode enabled, to check to see if the buffer has been modified more than flymake-no-changes-timeout seconds ago.

If you have a lot of buffers open (several hundred) in flymake-mode then this can devour a surprisingly large amount of CPU, I've a patched version of flymake that has a single global timer which fixes this, and a few other issues: https://github.com/illusori/emacs-flymake

This might not be the same issue for you, but for me it would lock Emacs up when opening in desktop-mode with 600 files open, I'd be lucky to get one keypress processed every 15 minutes.

Answer 3

On OS X I had a similar sounding problem where flymake would hang emacs when opening a new file (even with only a few buffers open). Enabling debug-on-quit didn't help, as the entire GUI locked up.

Attaching gdb to emacs returned the following:

$ gdb -p `psgrep emacs`
(gdb) bt
#0  0x00007fff98954e42 in __semwait_signal ()
#1  0x00007fff8e5d1dea in nanosleep ()
#2  0x00007fff99e3af05 in +[NSThread sleepUntilDate:] ()
#3  0x000000010015d917 in -[EmacsDialogPanel runDialogAt:] ()
#4  0x000000010015fa1f in ns_popup_dialog ()
[...]

So the lockup was caused by a dialog message saying "Configuration error has occurred while running ..." or similar

From this post describing the problem, you can disable these popup messages with the following:

Sometimes, however, Emacs just hangs. The OS X red/yellow/blue close/minimize/zoom buttons turn grey as if Emacs has lost focus, but it is in fact the active application. Switching tasks around and back to Emacs doesn't recover it. You can't Command-Q quit it.

When you do finally give up and kill it and restart, you've lost your work, your shells, and it doesn't save the list of recent-files.

(setq flymake-gui-warnings-enabled nil)

This prevents flymake from alerting you that it's switching itself off, but it's better than the alternative.

The flymake-display-warning calls Emac's 'message-box' function so there may be other tools which cause the same problem.

There's also a generic variable use-dialog-box but setting it from default t to nil didn't help with flymake. There's also a suggestion on the interwebs to use defadvice to tell y-or-no-p and yes-or-no-p set use-dialog-box to nil, but again, this won't help flymake since it doesn't use those functions.