-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
net.connection.onread handler: may crash on socket end #31823
Comments
@animetosho Do you think you could get a core dump for these? Or are you able to build modified versions of Node.js yourself? It would be great to know what the values of diff --git a/src/stream_base.cc b/src/stream_base.cc
index eaccfc995c74..ab69fa7c49e1 100644
--- a/src/stream_base.cc
+++ b/src/stream_base.cc
@@ -507,6 +507,7 @@ uv_buf_t CustomBufferJSListener::OnStreamAlloc(size_t suggested_size) {
void CustomBufferJSListener::OnStreamRead(ssize_t nread, const uv_buf_t& buf) {
+ fprintf(stderr, "OnStreamRead(%zd, %p), buffer_.base = %p\n", nread, buf.base, buffer_.base);
CHECK_NOT_NULL(stream_);
CHECK_EQ(buf.base, buffer_.base);
and then running seeing what the output before the failure is would be very helpful. (Alternatively, that information can probably be gathered from a core dump.) Fwiw, I can’t produce on x64 Linux, so … @nodejs/platform-macos |
Thanks for the response. I tried running it in GDB, but it looks like it can't identify those parameters. Doesn't look like the official binary packages include debug symbols (which would be useful to have...). Unfortunately I don't have access to any fast machines for a while, so compiling Node takes forever here, but I can try. If it's of any use, I've uploaded a core dump here. This is run with the official Node v13.8.0 binary so you should be able to load it with that. |
So I managed to get a compile working, though I question the accuracy of this build as it segfaults a lot. For a failure case, I get the following output:
|
If the `onread` socket option is used and a `POLLHUP` event is received, libuv returns `UV_EOF` along with a `NULL` buffer in the read callback, causing the crash. Deal with this case. Fixes: #31823 PR-URL: #32590 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com>
If the `onread` socket option is used and a `POLLHUP` event is received, libuv returns `UV_EOF` along with a `NULL` buffer in the read callback, causing the crash. Deal with this case. Fixes: #31823 PR-URL: #32590 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com>
If the `onread` socket option is used and a `POLLHUP` event is received, libuv returns `UV_EOF` along with a `NULL` buffer in the read callback, causing the crash. Deal with this case. Fixes: #31823 PR-URL: #32590 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com>
Just wanted to mention that I got this in Node 16.13.1 too. Seems hard to reproduce, only happens in our production environment with hundreds of different TLS connections..
Reverting to |
Just here to add that, whilst I'm unable to reproduce it myself, I've had someone else also report that it's still happening (issue referenced directly above your comment). Have no clue what the cause is, as it doesn't sound like a common case, but it seems not reliable enough to rely on. |
Experiencing the same issue here. Would have been nice to leverage the benefits of onread, but with an error like this it doesn't seem safe to use. Perhaps this issue could be reopened, or should I open another one? |
If the `onread` socket option is used and a `POLLHUP` event is received, libuv returns `UV_EOF` along with a `NULL` buffer in the read callback, causing the crash. Deal with this case. Fixes: nodejs/node#31823
When using an
onread
handler for net connections (issue #25436), it seems that the following assertion error may occur when the connection is closed:What steps will reproduce the bug?
This test requires a test server - I used the following code to run a test server on localhost:9999:
The actual test script (which connects to localhost:9999):
How often does it reproduce? Is there a required condition?
It doesn't happen that frequently - it usually takes around 4-30 attempts, using the test script above, for a crash to happen.
It seems that it is necessary for the server to send a message to cause the issue, even though the crash appears to be on connection end. The console output suggests that the crash occurs after the data is received, but before the
end
event is received.I haven't looked too much into the cause, but it doesn't seem to occur if the server and client are in the same script.
What is the expected behavior?
Test script should endlessly loop without crashing (if it doesn't crash within a few
hundredthousand cycles, I'd say it's successful).Output looks like:
What do you see instead?
Update: I've tried this on a few other systems. Haven't been able to reproduce on Node v13.8.0 on Windows x64. On another Linux x64 machine, it seems to have taken hundreds of cycles to reproduce.
The text was updated successfully, but these errors were encountered: