tls: nullify .ssl on handle close

[indutny]

This is an intermediate fix for an issue of accessing TLSWrap fields
after the parent handle was destroyed. While close listener cleans up
this field automatically, it can be done even earlier at the
TLSWrap.close call.

Proper fix is going to be submitted and landed after this one.

Fix: #5108

R = @bnoordhuis or @shigeki

cc @nodejs/crypto

[indutny]

CI: https://ci.nodejs.org/job/node-test-pull-request/1617/

@ChALkeR PTAL

[indutny]

@bnoordhuis @shigeki I think proper fix will be to avoid calling ~HandleWrap until the TLSWrap will die. Do you have any opinion on this?

[ChALkeR]

@indutny I will test this soon, sorry for the delay.

[indutny]

@ChALkeR no problem at all. Thanks for looking!

[indutny]

Gosh, forgot to commit test. Happens every other time!

[indutny]

New CI: https://ci.nodejs.org/job/node-test-pull-request/1618/

[ChALkeR]

The fix works for me in both the small and the original testcase, thanks!

[shigeki]

@indutny I still cannot figure out what causes this error. The test case seems to be equivalent to the followings and it also leads seg faults.

const server = tls.createServer(opts, function(c) {
  c.end();
}).listen(common.PORT, function() {
  var client = tls.connect({
    port: common.PORT,
    rejectUnauthorized: false
  }, function() {
    client.removeAllListeners('close');
    client.on('close', function() {
      setImmediate(function() {
        console.log(client.ssl);
      });
    });
    server.close();
  });
});

Does the bhttp module also remove or shift the built-in close listener? Otherwise does it have a something else other reason?

[ChALkeR]

Does the bhttp module also remove or shift the built-in close listener? Otherwise does it have a something else other reason?

/cc @joepie91 for bhttp.

[joepie91]

I can't say that I fully understand the issue or how it is being resolved (as I'm not very familiar with Node core yet), but the bhttp code does monkeypatch some stuff in one place.

I'm not touching close events anywhere, though, unless one of the dependencies involved is doing so. There's also not currently any special handling of HTTPS - it simply uses the https module instead of the http module.

[indutny]

@shigeki according to @joepie91 it is, but anyway this is that simplest test case that I could come with. The idea behind the fix is correct too.

[shigeki]

I've got that setImmediate causes this error as the bluebird module uses it as Promise scheduler.
When the callback of bhttp is invoked before destroySSL in the queues of setImmediate after the close event on TLSSocket, it leads the seg fault error. The error can be reproducible as

'use strict';
const common = require('../common');

if (!common.hasCrypto) {
  console.log('1..0 # Skipped: missing crypto');
  return;
}

const assert = require('assert');
const tls = require('tls');
const fs = require('fs');

const options = {
  key: fs.readFileSync(common.fixturesDir + '/keys/agent1-key.pem'),
  cert: fs.readFileSync(common.fixturesDir + '/keys/agent1-cert.pem')
};


const server = tls.createServer(options, function(s) {
  s.end('hello');
}).listen(common.PORT, function() {
  const opts = {port: common.PORT,
                rejectUnauthorized: false};
  const client = tls.connect(opts, function() {
    putImmediate(client);
  });
});


function putImmediate(client) {
  setImmediate(function() {
    if (client.ssl) {
      const fd = client.ssl.fd;
      assert(!!fd);
      putImmediate(client);
    } else {
      server.close();
    }
  });
}

The fix in this PR can resolve the issue. LGTM for a intermediate fix.

[indutny]

@shigeki do you mind if I will include your test? It seems to be much better than mine.

[shigeki]

@indutny No problem for using the test. I reconsider this fix in this PR and had a question. With this patch, ssl.destorySSL() is not invoked so that an SSL object seems to be never freed. Does it lead to leaking? How about using process.nextTick(destroySSL, this); in stead of setImmediate?

[thefourtheye]

If the intention is to fail the test here, why not assert it?

[indutny]

Because assert below will fail, and it won't crash.

[indutny]

Landed in aa05269, thank you!

[ChALkeR]

Thanks!