3

I've been having a problem lately where every few hours of use, for some reason I don't understand, Emacs stops responding to input without throwing an error. C-g and Esc-Esc-Esc do nothing, so I'm forced to kill Emacs and restart it. Presumably, this has something to do with a change I recently made to my .emacs, but I've made a lot of changes, and I don't see any good way to debug it. Recursively bisecting could entail spending weeks or months with a semi-functional editor, since the problem takes hours to show up and I don't know how to reliably reproduce it. Emacs isn't throwing an error, so debug on error doesn't help.

Is there some way I can start Emacs such that I can manually debug it on the fly, or so that it will give me a log of what Emacs was doing and I can look at the end to see what was going on when it stopped responding?

Improve this question
6
  • 2
    I suspect you'll need to provide more details, to obtain useful help with this. You've essentially presented only a black box (opaque) and hardly useful symptoms, and said that bisecting is not an option. Maybe you'll be lucky and get a helpful answer, but you don't provide much to go on. If I were you I'd bisect my init file. That's a binary search, so it's quick - modulo the need to wait for an intermittent problem to arrive or not.
    – Drew
    Apr 11 at 18:09
  • 1
    There may be a process or garbage collecting that appropriates all resources and that occults any keyboard seizure. You should monitor the active processes while blocking and / or memory status. These are things that happen to me because I have a machine that has enough resources. You should also try to launch Emacs in text mode to save graphic resources.
    – gigiair
    Apr 11 at 19:30
  • 1
    Is it just emacs that does not accept input? What system are you running on? Are you able to look around after emacs stops responding? You might try with emacs -q which bypasses your .emacs altogether: you'll lose your customizations, but if it does not encounter the problem, that would tend to confirm your .emacs hypothesis. The quickest way to deal with that is bisecting your .emacs as @Drew suggests. And you might want to keep your .emacs under source control in the future so you can easily go back to a previous version and test things out.
    – NickD
    Apr 11 at 21:06
  • 1
    To cover the one weird case I've experienced: Is it only keyboard input which stops working? The next time this happens, check whether you can still do things with the mouse. If so, and you're running a server, try firstly closing all of the existing frames, and then opening a new terminal frame and see if you can type in that.
    – phils
    Apr 13 at 5:41
  • 1
    @phils I am in fact able to interact with Emacs by mouse, but only via the global menubar (macOS). I can create a new frame, which I can interact with via keyboard (this is on a different computer than the one I made asynchronous), but when I closed the original frame, Emacs crashed and quit instantly. Sadly, because Emacs died, I did not get to test the pkill -USR2 emacs suggestion. (I don't think I'm using a server) [note: this is on a computer where I intentionally did not add the change to the Python script; I still have had no problems when the script is run asynchronously]
    – Zorgoth
    Apr 14 at 17:23
4

Sending the SIGUSR2 signal to Emacs should cause it to enter the debugger, interrupting whatever it was doing. See the help for the variable debug-on-event for more information.

Try running pkill -USR2 emacs in a shell.

Improve this answer
2
  • See this answer for details about emacs signal handling.
    – NickD
    Apr 13 at 17:12
  • Cool! Next time I have an Emacs in this state, I will try it out and see if it works.
    – Zorgoth
    Apr 14 at 14:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.