-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Read loop hangs after server stop #108
Comments
Thanks for the report. From my initial skim of the code, it looks as if there is a handler that is trying to call Stop on the server, and my guess is that is causing a deadlock. In general it won't be safe for a handler to stop its own server: while Stop holds the internal mutex to clean up the server state, it will exclude the reader from acquiring it while it shuts down. That in turn will cause the wait logic to never complete. If you'd like a handler to stop its server, you'll probably want to have it signal that a shutdown was requested, and do it from another goroutine after the handler exits. |
I poked at this a bit more, and another thing I noticed is that this language server appears to be using stdio to communicate (that is normal). Here, however, instead of the client closing its channel to the server, it sends the server a request to shut itself down. When the server stops, it calls If the client ignores this and leaves its write side open, the server will continue to wait, which is I think what you're seeing. Probably the simplest way to address this in your integration test is to either (a) make the client stop when it gets EOF from the server, or (b) make the shutdown process on the server side explicitly close its own stdin. E.g., perhaps adding here: os.Stdin.Close() I see from this that there is a documentation bug for |
The comment incorrectly stated that Close affects both sends and receives, when in fact it only affects sends. The receives affected by Close are at the other end of the channel pair. Updates #108.
Sorry for the late reply - I'll try out closing stdin and see what happens :). |
Closing stdin unfortunately doesn't fix the issue. Tried stopping the server within a go routine outside of the handler, but it still hangs.
|
I don't have a good theory about what's happening in this case. Is this the code that drives the server to the hang you are seeing? I don't see anything in that code that obviously calls your "exit" method, nor closes the pipe. Is there some other implicit plumbing that is doing so? |
Yeah, we removed shutdown and exit, as it was not working. But I tested with shutdown and exit and the process didn't quit. Locally the end of the test looks like this:
|
I attempted to build a minimal repro but it does not in fact reproduce what you're seeing. But perhaps it will give you a basis to isolate the conditions that are different in a way we can turn into a test? To use: unzip repro.sh
cd repro
make
./tcli |
We have encountered the situation, that our go executable does not return from WaitStatus.
Apparently, the goroutine to receive messages on the channel does not terminate after the server.stop, and thus the Wait does not return.
What kind of additional information would you need to analyse this in depth?
You can reproduce this running the
snyk-ls
executable, available at https://github.com/snyk/snyk-ls (we do that from an e2e test, located here).Please let me know if I can assist further.
The text was updated successfully, but these errors were encountered: