6

Sometimes Lisp hangs due to an infinite loop, making the whole of Emacs unresponsive, so it can't process any input, C-g included. So, I was hoping for there to be a way to maybe send it an emergency call from the outside, which would interrupt the Lisp interpreter, but would not kill Emacs altogether. I've experimented with sending some signals by means of kill -s <signal>, but Emacs seems to quit no matter what signal it is.

Gilles 'SO- stop being evil'
  • 21,702
  • 4
  • 53
  • 89
wvxvw
  • 11,222
  • 2
  • 30
  • 55

1 Answers1

4

It's possible to unconditionally enter the debugger by sending the value of debug-on-event (should be USR2 by default) as signal as documented in the Error Debugging section in the Emacs Lisp manual.

I found this rather useless to be honest since it just gave me a way to inspect a backtrace, not to unfreeze Emacs. YMMV obviously. As noted in the comments the other issue with this is that it won't work on Windows systems since those use neither kill nor signals for process communication.

wasamasa
  • 21,803
  • 1
  • 65
  • 97
  • It will only invoke debugger if there's some code executing, right? (I've tried sending it when Emacs is idle, and nothing happened, but Emacs didn't quit, so it's a plus). It is also useful to note that you need to check the value of `debug-on-event`, since for me this was `USR2`. I think that as long as I could drop into debugger I could either change the loop iterator variable or to throw to exit iteration... well, I'll check the next time this happens. Thanks though, much appreciated! – wvxvw Jan 20 '15 at 13:57
  • Right, fixed that. – wasamasa Jan 20 '15 at 15:18
  • 1
    As a note, this will not work on Windows (no `kill` command and does not use `signals` for communcation). – Jonathan Leech-Pepin Jan 20 '15 at 15:21