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
  • 810
  • 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

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.

db48x
  • 15,741
  • 1
  • 19
  • 23
  • See [this answer](https://emacs.stackexchange.com/a/44087/14825) for details about emacs signal handling. – NickD Apr 13 '21 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 '21 at 14:18