Closed hlolli closed 3 years ago
Ah! I've noticed something similar recently. I didn't notice any prettier-process (local) quit unexpectedly: hangup
messages and put it down to running an 28.x snapshot, and it's happening so rarely for me that so far I didn't feel the need to investigate more. But now, reading your bug report, it does sound like there might be something wrong with this package. It would be something in a recent version because it only started a month or two ago for me. I have a hunch it might be related to the new timeout handling in #78.
Could you install this version and see if that works better? I think you can do so with straight.el
or qelpa
and I'll also attach a tarball here soon.
You can use this link to download a Tarball: https://github.com/jscheid/prettier.el/suites/2172435994/artifacts/44656850
(You will have to unzip it to get the tar file).
Thanks for fast reply! I will test this one, tar file is good. I'm working today, so I should have results from this experiment tonight or tomorrow latest! I may even try some modifications to see if I can make sense of the problem. I don't want to guess, but I'm making some guesses in my mind to what could cause this. More later!
@jscheid following up, I've been using that tarball under heavy conditions. It stalled in total twice. Which is way way less than before (every hour on average before). It seemed to me that both of these stalls happened when I had multiple projects open with prettier mode and I was running prettier on multiple locations. Not sure if at the same time or around the same time. But I'm happy with how this is now and I definitely don't feel distracted.
Thanks for reporting back. Glad to hear it's working better now, I might revert that change then. But really it shouldn't stall, ever. The next time it does, after pressing C-g
, could you check the *prettier (local)*
buffer to see if there's anything in there and send it over if so?
yes, will do!
I missed an opportunity I guess. I'm not getting this buffer, it's not appearing on my buffer list. I only got
Saving file [hidden].js...
Wrote [hidden].js
Waiting for process to die...(type C-g again to kill it instantly)
Quit
prettier-process (local) quit unexpectedly: hangup: 1
I guess there must be some debug variable I need to set?
Ah, yes, sorry -- you need to set prettier-keep-server-buffer-flag
to non-nil.
2 weeks later, it's happening somewhat times a day. But the buffer *prettier (local)*
stays empty, before or after crashing.
@hlolli sorry for not having been very responsive, it's been a busy few weeks. I would still like to get to the bottom of it.
Re-reading your initial bug report, something caught my eye:
But very randomly, my Emacs hangs, I can't type for like a minute or two, so I repeat C-g constantly until this appears
I just wanted to check... does this happen when you save, or at other times? This package shouldn't be doing anything [1] when you're not saving, so that would be important to know.
[1] It does always wait on input from the sub-process in the background but that process would be idle outside of saving, and so there shouldn't be any reason for our handler to ever wake up.
It happens at any time, I had to do a factory reset on my macbook because of faulty update, and same on master as in the zip version you posted above. It can happen at any time, while Im doing anything unrelevant. It's even hanging while no js or web-tech buffer is open (currently editing nix and clojure files, and prettier is freezing now and then).
I'm starting to wonder whether prettier.el is a victim here rather than the perpetrator. It would be great if you could try a few things:
M-x list-processes RET
)? If so, could you do without them? It would be great if you could stop them and see if the hangs still happen.*prettier (local)*
buffer and then run list-processes
again to make extra sure it's gone. Note that the process will automatically start up again when you use it (e.g. when you save in a buffer for which prettier-mode
is enabled.)Also, a few more questions about your setup:
I wonder if this could be related to Big Sur Gatekeeper (OCSP). One way to find out would be to disable it using sudo spctl --master-disable
, but I can't really ask you to do that as it would disable a central element of MacOS security.
When I wrote the ticket, I used homebrew emacs, after my osx needed factory reset from faulty update, I've been on nix.
I'm starting to suspect either x86_64 vs ARM native node is somewhere miscommunicating. Or more likely the open filehandler limit is too low ($ ulimit -n ;; 256). This I started noticing in a react project after I did some upgrades, that many apps started crashing after the project started which led me to believe it's related what's happening here.
I'll try to upgrade to 28, there are more than 1 emacs mirror for nix packages which I could use. As well as upping the filehandler limit / configuring watchman better.
Feel free to close this, I see the code is super nice, google closure, top of the line minifier, so I can't see how prettier.el should be leaving a large trail. But somehow, the operating system kills it first before going on bigger apps (ex. Karabiner-Elements and Google-Chrome both tend to crash).
I'll maybe update on what configuration works best if I find good filehandler limit.
Interesting. It didn't occur to me that some resource limit might be causing the Node process to crash, but of course that is absolutely a possibility. Here are a few other things you could try:
--max-old-space-size
(but I think this might need a change to prettier.el)M-x list-processes
and then in a terminal run lsof -p <pid>
, mine has around 35-40 files open, so way below your ulimit of 256, but maybe it's different in your case? Good luck!
Describe the bug This may be one of the worst bug reports I've made. Since there's no way to reproduce this.
But very randomly, my Emacs hangs, I can't type for like a minute or two, so I repeat C-g constantly until this appears
Knowing that there's not much to do. An async handler or a force restart feature would make sense. This happens both on javascript with js-mode or in typescript with tide.
Link to
M-x prettier-info
outputTo Reproduce :(
Expected behavior Hangups can happen, but perhaps this can be less noticeable.
Additional context Tide also tends to hangup and exit, so this could be related to the nodejs process. Otoh, while at work, I have nodejs running all day, sometimes few days.