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?

Zorgoth
  • 840
  • 6
  • 14
  • 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 '21 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 '21 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 '21 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 '21 at 05:41
  • I think I might have found the source of the problem; inspired by @giglair's suggestion of a runaway process, I recalled that I have a command that runs frequently that calls a Python script. I think the Python script should always terminate, but given that I haven't seen the issue in a couple days since making the shell command that launches the script asynchronous, I may have to debug that script now. – Zorgoth Apr 14 '21 at 14:21
  • 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 '21 at 17:23

1 Answers1

5

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.

db48x
  • 17,977
  • 1
  • 22
  • 28