Fork me on GitHub
#emacs
<
2021-01-26
>
pithyless16:01:12

My emacs freezes up once in a while - could just be a spinning UI thread or an actual crash, but it is completely unresponsive and all I can do is kill the process, restart emacs, and restore the file. Any suggestions on how I can go about debugging or tracking this to identify what is the culprit? (My initial suspicion is perhaps aggressive-indent-mode - but I've got no proof :))

tvaughan16:01:23

Same. Is this on macOS? I'm hoping this problem doesn't exist on Linux. I don't use aggressive-indent-mode, but I've noticed this happens when moving around and editing a clojure buffer which could trigger font locking

pithyless16:01:57

yep, it's macOS and doom-emacs (if that's relevant)

Max Deineko16:01:58

Is it unresponsive even to receiving a SIGUSR2?

Max Deineko16:01:46

(I had encountered lsp-mode freezing when combined with clojure-mode lately, but nothing the usr signal would not interrupt)

pithyless16:01:38

I'm not using clojure-lsp, but thanks @U9TGHG3LP - I was not aware of SIGUSR2; (I was just forcing quit via Activity Monitor (which I assume does a pkill -9 ).

pithyless16:01:27

Next time I get it to reproduce (and manage to rescue it via SIGUSR2), is there anything I can run to help debug what was hogging the UI?

Max Deineko16:01:26

Usually usr2 will cause emacs to enter the debugger, so that you should be able to pinpoint at least some execution point related to the problem.

👍 2
👏 1
rickmoynihan10:02:52

I’ve had this same issue/symptom too… It happens quite frequently, but not enough to easily debug it. Also on macos M-x emacs-version

GNU Emacs 27.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G95))
 of 2020-08-12

pithyless16:02:47

It's happening less frequently now (I think), but unfortunately in my setup pkill -SIGUSR2 just exits emacs (without putting it in a debugger state). This maybe something with the way doom-emacs is configured by default, but I had not investigated further yet.

pithyless16:02:26

GNU Emacs 27.1.50 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G6042)) of 2020-11-17

tvaughan18:02:24

This just happened to me again. Looks like it had something to do with the modeline, telephone line specifically

rickmoynihan08:02:38

Interesting, @U0P7ZBZCK what makes you think that? FWIW I’m running doom-modeline (but my own emacs config)

tvaughan11:02:11

That’s what came up in the debugger. I didn’t see anything that looked incorrect though. Could have just been a coincidence that’s where emacs was at the time when I sent USR2. I’ll see what happens next time. Hopefully there’s at least a consistency to this problem

rickmoynihan12:02:38

FYI I disabled doom-modeline out of interest yesterday, and so far I’ve not seen emacs crash — so could be promising, but too early to say for sure

pithyless16:02:19

thanks everyone for contributing data points to this thread!