tls: emit errors on close whilst async action

[indutny]

When loading session, OCSP response, SNI, always check that the
self._handle is present. If it is not - the socket was closed - and we
should emit the error instead of throwing an uncaught exception.

Fix: nodejs/node-v0.x-archive#8780
Fix: #1696

[indutny]

cc @iojs/crypto

[migounette]

@indutny You fixed at the JS part by checking the _handle, but what I found during an intensive play with TLS is that the _encout was NULL (a C++ level). It is a kind of SSL Close issue race condition (for me), but I need to change the test case because it's very difficult for me to reproduce.

Thanks for the fix

[indutny]

@migounette@EricTheOne: I have updated the PR, please take a look

[EricTheOne]

@indutny thanks, applied both patches in order on v2.0.2, getting a segfault elsewhere (maybe it's progress):

Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000d18d00 in node::StreamBase::EmitData(long, v8::Local<v8::Object>, v8::Local<v8::Object>) ()
(gdb) bt
#0 0x0000000000d18d00 in node::StreamBase::EmitData(long, v8::Local<v8::Object>, v8::Local<v8::Object>) ()
#1 0x0000000000d3cc8a in node::TLSWrap::OnReadSelf(long, uv_buf_t const*, uv_handle_type, void*) ()
#2 0x0000000000d40d19 in node::TLSWrap::OnReadImpl(long, uv_buf_t const*, uv_handle_type, void*) ()
#3 0x000000000084fa02 in v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) ()
#4 0x0000000000876c1b in v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) ()

[indutny]

@EricTheOne pushed one more commit, PTAL

[EricTheOne]

@indutny I've applied all three commits in order, on v2.0.2. Getting a different segfault now:

Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00000000030f1490 in ?? ()
(gdb) bt
#0 0x00000000030f1490 in ?? ()
#1 0x0000000000d40d29 in node::TLSWrap::OnReadImpl(long, uv_buf_t const*, uv_handle_type, void*) ()
#2 0x000000000084fa02 in v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) ()
#3 0x0000000000876c1b in v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) ()

[indutny]

@EricTheOne looks like I don't fully understand problem yet. Any way I can reproduce it locally?

[indutny]

Just a heads up, @evanlucas discovered a crash in a test: https://gist.github.com/evanlucas/6ab0a62ebe7ffa5d0ddf

It is reproducible after patching the test suite:

diff --git a/test/parallel/test-tls-js-stream.js b/test/parallel/test-tls-js-stream.js
index e156f44..292bd4f 100644
--- a/test/parallel/test-tls-js-stream.js+++ b/test/parallel/test-tls-js-stream.js@@ -61,6 +61,7 @@ var server = tls.createServer({
socket.end('hello');
socket.resume();
+ socket.destroy();
});
socket.once('close', function() {

Going to investigate it in detail later.

[indutny]

@evanlucas and it is actually fixed by this commit ad3a799

[indutny]

Erm, not by commit, rather by this PR.

[evanlucas]

yay!

[indutny]

Which is kind of sad for the @EricTheOne's thing...

[indutny]

CI: https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/730/

[indutny]

@migounette@EricTheOne any news? ;)

[indutny]

CI (with style fixes): https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/747/

[indutny]

CI is green.

[trevnorris]

@indutny going to merge this?

[indutny]

Yeah, let's land it. @trevnorris LGTY?

[trevnorris]

LGTM

[indutny]

Landed in 5795e83, 75930bb, and 59d9734. Thank you!

[thefourtheye]

Not sure if the error message sounds like a TypeError

[indutny]

Yeah, I think it is worth submitting a follow-up fix PR. ;)

[thefourtheye]

@indutny I feel that the default types of Errors is not enough. We should at least have something like ValueError. What do you think?

[indutny]

I'd say it might be too expensive to create them in C++, unless I'm missing something obvious.

[thefourtheye]

I locally created a patch which fixes all the inconsistent error messages like this, in the js files. And I had an internal/errors.js file which defined ValueError. Looks like that solves most of the wrong data error messages. But I am not sure if it is worthy introducing a new Error type.

[indutny]

Yeah, I don't think anyone really checks the type of error. It kind of serves only an informational purpose when it pops up in the stderr.