Skip to content
Closed
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
fixes
  • Loading branch information
indutny committed Nov 14, 2016
commit e6869b87035949da59bbd2d0a9df44cc8f33f39f
2 changes: 1 addition & 1 deletion lib/_tls_wrap.js
Original file line number Diff line number Diff line change
Expand Up @@ -321,7 +321,7 @@ tls_wrap.TLSWrap.prototype.close = function close(cb) {
ssl._secureContext.context = null;
}
}
if (cb)
if (typeof cb === 'function')
cb();
};
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious, what would happen when ssl.destroySSL() gets called synchronously, i.e., outside the callback?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Crash, because of StreamBase callbacks.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason is actually way simpler than this, I'll simplify the code.

Thank you for bringing my attention to this.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It crashes if done in the same tick because it may be invoked within the OpenSSL's call stack. If invoked with setImmediate - it won't crash.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh... just run the test suite after using setImmediate() and it confirms my initial assumption. Sorry, not going to fix it.

The write callbacks are invoked with UV_ECANCELED and thus things are getting back to tls_wrap.cc at places where it doesn't expect ssl_ to be nullptr. Therefore it is better to free it up after closing the underlying libuv handle.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be honest, I'm so unhappy with what we have right now (I know that I wrote most of it). I wish we would move to uv_ssl_t.


Expand Down
2 changes: 1 addition & 1 deletion test/parallel/test-tls-writewrap-leak.js
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ const server = net.createServer(common.mustCall((c) => {
});

c.write('hello', common.mustCall((err) => {
assert.equal(err.code, 'ECANCELED');
assert.deepEqual(err.code, 'ECANCELED');
server.close();
}));
}));