-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
failed test: parallel/test-tls-inception.js #1012
Comments
This test fails on SmartOS as well (upcoming build slave in the jenkins test cluster) with the same behaviour. |
Reproduced the problem, working on the isolating it. |
Seems to coming from this syscall:
|
Nope, it isn't. Guess we are not closing the socket at the right time... or closing it way too early on other side. Will figure it out later, doesn't seem to be a C++ issue from the first sight, just a behavior change... :( |
Small log:
|
dtruss output: |
Fix test failure on FreeBSD and SmartOS, which happens due to a bad timing: events.js:141 throw er; // Unhandled 'error' event ^ Error: read ECONNRESET at exports._errnoException (util.js:734:11) at TLSWrap.onread (net.js:538:26) The outer `net.conncet()` socket stays alive after the inner socket is gone. This happens because `.pipe()`'s implementation does not `destroy` the source side when the destination has emitted `close`. Fix: nodejs#1012
Should be fixed by #1040 |
Fix test failure on FreeBSD and SmartOS, which happens due to a bad timing: events.js:141 throw er; // Unhandled 'error' event ^ Error: read ECONNRESET at exports._errnoException (util.js:734:11) at TLSWrap.onread (net.js:538:26) The outer `net.conncet()` socket stays alive after the inner socket is gone. This happens because `.pipe()`'s implementation does not `destroy` the source side when the destination has emitted `close`. Fix: #1012 PR-URL: #1040 Reviewed-By: Chris Dickinson <christopher.s.dickinson@gmail.com>
Confirmed fixed. Closing. |
this is not fixed just seen in on V 1 - 4 - 13 |
@nikolmarku1 on the what now? What node/iojs version on what os are you running? |
I'm also seeing a similar issue on v4.2.1 stack running on heroku.
|
Seeing on AWS 4.2.1 - inconsistently |
This test fails on FreeBSD 10.1-release:
git bisect
tells me that b968623 is the offending commit (verified by running parent 4 times). Unfortunately, this seems to be race-y./cc @indutny
The text was updated successfully, but these errors were encountered: