Skip to content
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

Stream read errors result in uncaught exceptions #270

Closed
hansonw opened this issue Nov 7, 2017 · 11 comments
Closed

Stream read errors result in uncaught exceptions #270

hansonw opened this issue Nov 7, 2017 · 11 comments
Labels
help wanted Issues identified as good community contribution opportunities

Comments

@hansonw
Copy link

hansonw commented Nov 7, 2017

Currently, message errors from StreamMessageReader's onData method end up as uncaught exceptions, which can be very difficult to handle when used in server contexts.

https://github.com/Microsoft/vscode-languageserver-node/blob/master/jsonrpc/src/messageReader.ts#L220

Would it be reasonable to convert such errors into error events (via this.fireError) so that the stream owner can perform shutdown / restart steps as necessary? I can submit a PR to do so. cc @ljw1004

@dbaeumer
Copy link
Member

dbaeumer commented Nov 8, 2017

Yes, but we should clearly defined that the readere then moves into an error state and doesn't process any new onData events since it can not meaningful recover from a missing content length.

@dbaeumer dbaeumer added the help wanted Issues identified as good community contribution opportunities label Nov 8, 2017
@dbaeumer dbaeumer added this to the Backlog milestone Oct 28, 2019
@raxod502
Copy link

raxod502 commented Jul 9, 2020

Any workaround? It is really really bad if your server crashes just because some LSP stream got broken. Depending on context, could be a security vulnerability.

@dbaeumer
Copy link
Member

The got improved already an errors are now reported on the connection. What esle do you expect the reader to do if it receives a broken message

@raxod502
Copy link

When an error occurs, the entire Node.js process is crashed for me. Do I have to register an error handler to prevent this from happening, or am I doing something else wrong that is causing me to mistakenly blame this package?

@dbaeumer
Copy link
Member

Not sure I understand that correctly. The server node process crashes ?

@raxod502
Copy link

raxod502 commented Aug 17, 2020

Yes. The Node.js process that is running vscode-languageserver-node crashes (after printing stack trace from vscode-languageserver-node).

@dbaeumer
Copy link
Member

What seems strange to me is that the node process crashes. It shouldn't :-)

But I am open for a PR that converts the exception into a fireError.

@raxod502
Copy link

In particular this is what is printed before the server crashes.

/home/docker/src/node_modules/vscode-jsonrpc/lib/messageReader.js:163
                    throw new Error('Header must provide a Content-Length property.');
                    ^

Error: Header must provide a Content-Length property.
    at StreamMessageReader.onData (/home/docker/src/node_modules/vscode-jsonrpc/lib/messageReader.js:163:27)
    at Socket.<anonymous> (/home/docker/src/node_modules/vscode-jsonrpc/lib/messageReader.js:148:18)
    at Socket.emit (events.js:314:20)
    at addChunk (_stream_readable.js:303:12)
    at readableAddChunk (_stream_readable.js:279:9)
    at Socket.Readable.push (_stream_readable.js:218:10)
    at Pipe.onStreamRead (internal/stream_base_commons.js:188:23)

@raxod502
Copy link

raxod502 commented Aug 23, 2020

What seems strange to me is that the node process crashes. It shouldn't :-)

I just tested, and uncaught exceptions do (in general) crash Node. I believe this is intended behavior. Test:

% node -e "setTimeout(() => { throw new Error('foo') }, 1000); setTimeout(() => console.log('done'), 2000)"
[eval]:1
setTimeout(() => { throw new Error('foo') }, 1000); setTimeout(() => console.log('done'), 2000)
                   ^

Error: foo
    at Timeout._onTimeout ([eval]:1:26)
    at listOnTimeout (internal/timers.js:551:17)
    at processTimers (internal/timers.js:494:7)

@dbaeumer
Copy link
Member

OK. Now I understand. Under crash I was assuming a real process crash.

For the servers I maintain I have a process.on('uncaughtException', (error: any) => { ... }) handler since exception can occur in other parts of your server as well.

@dbaeumer
Copy link
Member

dbaeumer commented Oct 6, 2020

This got addressed in the meantime. The exception are now reported via the onError event.

@dbaeumer dbaeumer closed this as completed Oct 6, 2020
@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 20, 2020
@dbaeumer dbaeumer removed this from the Backlog milestone Oct 24, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
help wanted Issues identified as good community contribution opportunities
Projects
None yet
3 participants