REPL periodically freezes Emacs #344
Comments
|
One quick thought I have would be to try with the latest from MELPA. On the one hand that's the general area I would expect could cause the kind of "Emacs freeze" you describe. On the other hand, none were intended to fix that problem. (I haven't seen that myself, and I leave racket-repl-mode open for days/weeks at a time. I'm sure you're seeing it! I'm just saying I didn't know this was a problem so didn't try to fix it.) On the third hand, maybe one change did so inadvertently. I'll mull this over but in the meantime if it's not too inconvenient please try the latest? Note: It might be slightly inconvenient because you might need to restart Emacs. (Due to issue #327 changing the back end startup "API". And due to Emacs package updates not necessarily "refreshing" already-loaded Emacs code.) |
|
In terms of gathering more data:
|
|
Ah good call on updating Will take it for a spin and report back. |
|
Hopefully a spin not a spinlock. kick snare cymbal |
|
I noticed a similar problem, but running on Windows: sometimes, when the laptop comes out of sleep, the Racket process for the REPL uses 100% CPU. Emacs is however responsive and I can just kill the REPL buffer and start fresh. This does not happen every time the laptop is resumed from sleep, so I don't actually know what the trigger is. I had this problem for several Racket versions and several racket-mode versions (I update regularly) -- it is something I learned to live with, as it is not a major inconvenience. When this happens, I sometimes get a message in the REPL about the event space being unexpectedly closed, so I suspect it has something to do with the GUI libraries. Unfortunately I don't use DrRacket often enough to know if it suffers from the same problem... |
|
Okay, following up. For the most part updating Emacs eventually recovered after hanging for about a minute. Unclear if the problem was with trying to connect to Racket or some interplay with |
I noticed when testing on Windows, that sometimes the connection would not succeed, and furthermore get stuck in a state where racket--cmd-connecting-p was left non-nil. This commit fixed that for me. Although this might have some bearing on issue #344 and issue #348, I don't have any reason to think this fixes those.
I noticed when testing on Windows, that sometimes the connection would not succeed, and furthermore get stuck in a state where racket--cmd-connecting-p was left non-nil. This commit fixed that for me. Although this might have some bearing on issue #344 and issue #348, I don't have any reason to think this fixes those.
|
Thanks! I can reproduce this specific situation with both conditions:
There is code that avoids starting the Racket REPL solely for completion candidates (instead it defaults to names we font-lock). However it's getting fooled when the edited buffer lacks any file, and there is no file associated with the REPL; both are That is a simple fix, which I just made locally, but haven't yet pushed. I'm a little freaked out by this part of your output: There is no way that three racket command processes ought to be created. So I need to investigate that. |
|
Thanks for the follow up @greghendershott I ran into this yesterday at work trying to help a colleague debug something. Got the Looking forward to the release with the fix, thanks again! |
|
You're welcome. Caveat: This fix is very specific to the situation where you go to some buffer like So if you discover some other failure mode(s), (a) sorry! and (b) please let me know. |
|
Hello, stumbled on this bug. I have version
As a side note, I'm a big emacs newbie and currently use Spacemacs |
|
Same: "Still trying to connect to racket-command process on port 55555" on company completion (company-mode disable can prevent this) |
|
Please reopen this, I use lastest racket-mode from git! |
|
@11111000000 FWIW that sounds closer to #359 i.e. @octplane Possibly same in your case. IIRC Also related is #349 from mid-January tagged I will try to dig into this soon. If I don't have time to figure it out for real, maybe I could at least put a Band-Aid on like setting the company-mode popup delay to the value that means "never popup automatically, I press a special keybinding when I want you". |
|
p.s. I don't think you need to blow away your entire packages folder! Instead this:
|
|
@11111000000 If that "deep update" process doesn't help, can you please give a step-by-step recipe so I can reproduce? Also M-x racket-bug-report will let me see some Emacs vars that might have an impact. I ask because I just tried this:
Result: Company pops up with a list of completion candidates. (Pick one, all is well.) Note that ever since commit b0296d9 in July 2018, in the above steps it is not even necessary for the You must be doing something at least slightly different? If so, please tell me. Meanwhile I'll try some other steps to see if I can stumble across it before you can tell me.... |
|
p.s. My company-mode config in init.el is: (use-package company
:ensure t
:defer t
:diminish company-mode
;; The following for testing racket-mode/issues/318
:config
(setq company-idle-delay 0.1
company-minimum-prefix-length 2
company-tooltip-align-annotations t
company-show-numbers t
company-require-match nil))How about you? Also can you give me the Thanks. |
|
I just had this problem happen to me while trying to run a simple program: #lang racket
(define x 1)When running the above using Also, I am not using I suspect there might be a race condition somewhere, but not sure where. If I manage to reproduce it again, I will attempt to debug it further... |
|
@alex-hhh That jogs my memory: I was using racket-mode heavily on Windows about a month ago, and ISTR this happened once. But not thereafter. 😞 At the time I was trying to fix some other issues on Windows, and forgot. The proximate cause might be that |
I noticed when testing on Windows, that sometimes the connection would not succeed, and furthermore get stuck in a state where racket--cmd-connecting-p was left non-nil. This commit fixed that for me. Although this might have some bearing on issue #344 and issue #348, I don't have any reason to think this fixes those. ----------------------------------------------------------------- PROVENANCE: Today I noticed commit 98bb9c7 and commit cedf4ba linked to from the above issues. But I do not have either commit in any of my local repos, not even according to `git fsck --lost-found`. WAT. I suspect what happened was that I made a topic branch and pushed a commit, which is why GitHub got it (and apparently will keep it indefinitely because of the link from comments). But then I deleted the branch without merging. Or possibly that commit was rebased away before merging the branch. Probably this happened on a new Windows laptop. In my defense, mid-January I was moving between Mac and Windows, as part of an effort to improve racket-mode support on the latter. And then, a Linux laptop got added to the mix, as well. In any case I'm going to recover and use this commit, now. The bit above the horizontal line is the commit message.
Goal: Fix any remnants of issue #344. - Simplify code paths by relying on sentinels to do cleanup when the process is deleted or closed. - Analyze the remaining paths to ensure that racket--cmd-connecting-p is set t during a series of connection attempts, and, set back to nil after such a series has completed (whether succeeded, failed, or C-g by the user). - Break out the guts of racket--cmd-connect-start to a helper racket--cmd-connect-attempt. This makes it clearer that the former does checks needed at the start of the series, and the latter is called at intervals via run-at-timer to "run in the background". - Rather than setting racket--cmd-proc back to nil, leave it set to the last value, and use things like `process-status` determine if it is 'open. Provide a little helper for this: racket--cmd-open-p. - Add more (and hopefully better) comments and doc strings.
|
@alex-hhh thanks for the tip on |
|
@DarrenN I just pushed a commit 72a54ad (to a topic branch, not yet to master) adding a reminder. I've been spending a lot of time this weekend trying to understand and eliminate this issue. (I'd find this easier to do with Racket's concurrency primitives and tools, but I'm doing the best I can with Emacs Lisp.) e.g. commit 82a381d tries to simplify the code paths, and make sure all handle things correctly. And commit 7020209 tries to narrow it down even more. I've done a little testing on Windows -- which is the only place I've experienced this heisenbug, even rarely -- and also on Linux, including putting intentional timing delays in certain places to try to flush it out more readily. Obviously not going to make any predictions about the success, yet. |
|
Still working on this. I'm starting to think that the root problem is that, when something needs to send a command, currently we try to helpfully and automagically start the REPL backend and connect to its command server. This creates code paths like:
I'm starting to think the best thing to do is just issue an error: Tell the user, "Yeah, sorry, can't do that. You need to start the REPL first." Or sometimes, "Yeah, sorry, although the REPL is live, the command server doesn't seem to be. Looks like you'll need to restart the REPL." That might flush out some new set of bugs or annoyances -- but I think they'll be deterministic bugs and annoyances. So I'll work on that as I have time... |
|
Found more hours to work on this. Same vein as above. WIP commits on a topic branch |
|
Hi @greghendershott, I had a brief look at the code, as it is on the Also, given that this issue cannot be reproduced, perhaps it would be better to just update the code to add some more logging, and ask the users who encounter this issue to report the contents of their
|
|
Hi @alex-hhh, thank you for taking a look at this. I think you're right that's one problem the Another problem is that anyone or anything could delete the racket-command process-buffer, and therefore also the process, and the code will be confused. What I've been working on goes a little further. I have about 21 commits where I've been simplifying and changing things one step at a time, and leaving breadcrumbs. A quick summary:
|
|
@greghendershott Now, there is no issue here for me. |
I noticed when testing on Windows, that sometimes the connection would not succeed, and furthermore get stuck in a state where racket--cmd-connecting-p was left non-nil. This commit fixed that for me. Although this might have some bearing on issue #344 and issue #348, I don't have any reason to think this fixes those. ----------------------------------------------------------------- PROVENANCE: Today I noticed commit 98bb9c7 and commit cedf4ba linked to from the above issues. But I do not have either commit in any of my local repos, not even according to `git fsck --lost-found`. WAT. I suspect what happened was that I made a topic branch and pushed a commit, which is why GitHub got it (and apparently will keep it indefinitely because of the link from comments). But then I deleted the branch without merging. Or possibly that commit was rebased away before merging the branch. Probably this happened on a new Windows laptop. In my defense, mid-January I was moving between Mac and Windows, as part of an effort to improve racket-mode support on the latter. And then, a Linux laptop got added to the mix, as well. In any case I'm going to recover and use this commit, now. The bit above the horizontal line is the commit message.
Goal: Fix any remnants of issue #344. - Simplify code paths by relying on sentinels to do cleanup when the process is deleted or closed. - Analyze the remaining paths to ensure that racket--cmd-connecting-p is set t during a series of connection attempts, and, set back to nil after such a series has completed (whether succeeded, failed, or C-g by the user). - Break out the guts of racket--cmd-connect-start to a helper racket--cmd-connect-attempt. This makes it clearer that the former does checks needed at the start of the series, and the latter is called at intervals via run-at-timer to "run in the background". - Rather than setting racket--cmd-proc back to nil, leave it set to the last value, and use things like `process-status` determine if it is 'open. Provide a little helper for this: racket--cmd-open-p. - Add more (and hopefully better) comments and doc strings.
I noticed when testing on Windows, that sometimes the connection would not succeed, and furthermore get stuck in a state where racket--cmd-connecting-p was left non-nil. This commit fixed that for me. Although this might have some bearing on issue #344 and issue #348, I don't have any reason to think this fixes those. ----------------------------------------------------------------- PROVENANCE: Today I noticed commit 98bb9c7 and commit cedf4ba linked to from the above issues. But I do not have either commit in any of my local repos, not even according to `git fsck --lost-found`. WAT. I suspect what happened was that I made a topic branch and pushed a commit, which is why GitHub got it (and apparently will keep it indefinitely because of the link from comments). But then I deleted the branch without merging. Or possibly that commit was rebased away before merging the branch. Probably this happened on a new Windows laptop. In my defense, mid-January I was moving between Mac and Windows, as part of an effort to improve racket-mode support on the latter. And then, a Linux laptop got added to the mix, as well. In any case I'm going to recover and use this commit, now. The bit above the horizontal line is the commit message.
Goal: Fix any remnants of issue #344. - Simplify code paths by relying on sentinels to do cleanup when the process is deleted or closed. - Analyze the remaining paths to ensure that racket--cmd-connecting-p is set t during a series of connection attempts, and, set back to nil after such a series has completed (whether succeeded, failed, or C-g by the user). - Break out the guts of racket--cmd-connect-start to a helper racket--cmd-connect-attempt. This makes it clearer that the former does checks needed at the start of the series, and the latter is called at intervals via run-at-timer to "run in the background". - Rather than setting racket--cmd-proc back to nil, leave it set to the last value, and use things like `process-status` determine if it is 'open. Provide a little helper for this: racket--cmd-open-p. - Add more (and hopefully better) comments and doc strings.
People continue to report symptoms like issue #344. In some cases it turned out people needed to update to the latest racket-mode. However at least a couple users on very recent versions reported still seeing the problem intermittently. So: - Simplify code paths by relying on sentinels to do cleanup when the process is deleted or closed. - Rename racket--repl-ensure-buffer-and-process to racket--repl-start, and, it is an error to call it when (racket--repl-live-p) is true. - Rather than setting racket--cmd-proc back to nil, leave it set to the last value, and use things like `process-status` determine if it is 'open. Provide a little helper for this: racket--cmd-open-p. - Wait to start command connect; eliminate racket--cmd-connecting-p state variable. Until we believe the Racket backend has finished starting up and the TCP server would be listening, there is really no point in starting to attempt to connect. Ideally we could know this from a process sentinel, but there is no appropriate event for a comint buffer process. Instead use a comint output filter function to detect first output, e.g. the Welcome to Racket banner. This uses run-at-time to schedule racket--cmd-connect-attempt (should not do directly from a filter function, IIUC). As a result, there is no longer any racket--cmd-connect-start function. Now, we only try to connect to the command server when we first start the REPL process. If the command connection dies thereafter, but the REPL is still alive? Tough beans, users will need to restart the REPL process. Also as a result, I convinced myself that the racket--cmd-connecting-p flag/guard is no longer necessary. Which is good, because it is tricky to make all the code paths manage that properly. I _think_ I finally got that right in a WIP commit. But it's fragile. Some other change, someday, could break this again. Better users get a "can't talk to command server" error, and need to restart the REPL, than have heisenbugs and reports thereof. Note: As before, racket--cmd-connect-attempt will run-at-time itself to retry: We wait until the TCP command server could _possibly_ be ready -- but it's not necessarily ready yet. Although it will probably succeed on the first try, in fact I've seen it occasionally take two attempts while testing this on a laptop/OS that does the startup very quickly. - racket-repl-exit: Use comint-kill-subjob when command server dead - Add defcustom racket-command-startup. - When nil (default): We do not try to start the REPL or the command server automatically; instead we give the user an error message explaining they need to (re)start racket-repl-mode. - When a positive number, we do try to start things automatically and we wait that number of seconds for the command server to connect. While waiting, we remind the user they can C-g to quit waiting.
|
@11111000000 Glad to hear that. @DarrenN and @alex-hhh If you still encounter this, you might want to try upgrading to use my latest commit 1e46dc5, which is a squash of the 20+ commits I worked on over the past week, and just merged to This adds a |
Background
I wanted to start this issue so I can being gathering more information.
Periodically when I have the Racket REPL open in
racket-modeEmacs will freeze and peg a core at 100%. I cannot determine when it will happen. Sometimes I will step away from my laptop for a moment and come back and its hung, other times I will be in the middle of editing code and it will freeze. I'm not 100% sure its related to the REPL, but it only happens when I have the REPL open. I have to force quit Emacs via Activity Moniotor when this happens. Sometimes its gets really bad and I revert to running code on the CLI instead of using the REPL.The code I'm working on it isn't doing anything fancy with threads that would block the REPL (and even when I do I can break out with C-c).
What other information can I grab? When it does lock I can sample the running process from OSX's Activity Monitor.
Debug information
The text was updated successfully, but these errors were encountered: