Skip to content
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

async_hooks,http: fix socket reuse with Agent #13348

Closed
wants to merge 1 commit into from

Conversation

addaleax
Copy link
Member

Under very specific circumstances the http implementation could be brought to crash, because the Agent did not re-assign the async id field properly after setting up a socket for reuse.

Fixes: #13325

/cc @nodejs/async_hooks and @Trott because this is a somewhat complex test file

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

http, async_hooks

Under very specific circumstances the `http` implementation
could be brought to crash, because the Agent did not re-assign
the async id field properly after setting up a socket for reuse.

Fixes: nodejs#13325
@addaleax addaleax added async_hooks Issues and PRs related to the async hooks subsystem. http Issues or PRs related to the http subsystem. labels May 31, 2017
@nodejs-github-bot nodejs-github-bot added the http Issues or PRs related to the http subsystem. label May 31, 2017
}
}, common.mustCall((res) => {
const asyncId = res.socket[async_id_symbol];
assert.ok(asyncId > 0, `${asyncId} > 0`);
Copy link
Member Author

Choose a reason for hiding this comment

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

Commenting out this assertion will give you back the hard crash that we were seeing in the issue.

Copy link
Contributor

Choose a reason for hiding this comment

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

Commenting out and removing the fix?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes. 😄

@@ -168,6 +168,7 @@ Agent.prototype.addRequest = function addRequest(req, options, port/*legacy*/,
var socket = this.freeSockets[name].shift();
// Assign the handle a new asyncId and run any init() hooks.
socket._handle.asyncReset();
socket[async_id_symbol] = socket._handle.getAsyncId();
Copy link
Contributor

Choose a reason for hiding this comment

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

👍 This is what I was referring to
"Race" was an inexact word

Copy link
Contributor

@refack refack May 31, 2017

Choose a reason for hiding this comment

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

I don't know why but my intuition was to do this somewhere in a Socket method.
Maybe move both lines to a Socket method so other Agents could use it.
Something like Socket.prototype._prepareForReuse() or _recycle

Copy link
Member Author

@addaleax addaleax May 31, 2017

Choose a reason for hiding this comment

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

Hmm … doing it this way doesn’t introduce any new methods that are accessible to the outside world. I am okay with moving it, but that should be based on more consideration than just fixing this bug; as you pointed out in the issue, we would want to consider what kind of API, if any, custom Agent implementations need.

So: I’m not disagreeing, but I think it’s better to postpone that after landing this.

edit: If we do this, we should probably also move the other part (marking the socket as free for reuse).

Copy link
Contributor

Choose a reason for hiding this comment

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

Agreed

Copy link
Contributor

Choose a reason for hiding this comment

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

For the moment I'd say this is the correct way to handle the fix, and was an oversight on my part.

@refack

I don't know why but my intuition was to do this somewhere in a Socket method. Maybe move both lines to a Socket method so other Agents could use it. Something like Socket.prototype._prepareForReuse() or _recycle

Technically async_id_symbol was only added as a convenience to skip calling into native and retrieving AsyncWrap::async_id_, but in reality is unnecessary. The most sure way to handle this would be to remove all uses of async_id_symbol where there is a 1:1 pairing of native resource to JS resource and always call getAsyncId().

@addaleax

we would want to consider what kind of API, if any, custom Agent implementations need.

Node allows custom implementation of agents, timers and a few others. Which is the reason why getNewAsyncId() in lib/net.js checks if getAsyncId === 'function' and why insert() in lib/timers.js forcefully adds a new asyncId if none already exists. It has been a total pain during development, and the existing solution is the best I could come up with. Though if you have a better idea I would be happy to try it out.

@addaleax
Copy link
Member Author

assert.strictEqual(r1.socket, socket);

res.on('data', common.mustCallAtLeast(() => {}));
res.on('end', common.mustCall(() => {
Copy link
Contributor

Choose a reason for hiding this comment

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

in 6bfdeed I used res.socket.once('free'
Might be simpler than on(end, setImmediate)

Copy link
Member

@AndreasMadsen AndreasMadsen left a comment

Choose a reason for hiding this comment

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

Well done!

LGTM. I can confirm that this does fix a bug and that it corresponds to the ClientRequest._writeRaw (_http_outgoing.js:279:9) callsite from the stack trace provided in #13325 (comment)

The test looks sufficient, I haven't spend a lot of time reviewing it.

@refack
Copy link
Contributor

refack commented May 31, 2017

res.on('data', common.mustCallAtLeast(() => {}));
res.on('end', common.mustCall(() => {
// setImmediate() to give the agent time to register the freed socket.
setImmediate(common.mustCall(() => {
Copy link
Member

Choose a reason for hiding this comment

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

Probably can leave out common.mustCall() on a setImmediate() but no harm either I suppose.

Copy link
Contributor

Choose a reason for hiding this comment

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

While this isn't an issue, and most likely will never be, there is actually a case that could cause some confusion:

require('async_hooks').createHook({ destroy() { process.exit() }}).enable();
process.on('exit', () => process._rawDebug('exiting...'));
require('net').createServer().listen(0).close();
setImmediate(() => process._rawDebug('setImmediate'));

But that's just for reference. You're most likely correct that's it's unnecessary. But never hurts either. :)

@Trott
Copy link
Member

Trott commented May 31, 2017

/cc @nodejs/testing for reviews of the test file

@addaleax
Copy link
Member Author

addaleax commented Jun 3, 2017

Landed in 3e02636

@addaleax addaleax closed this Jun 3, 2017
@addaleax addaleax deleted the fix-13325 branch June 3, 2017 20:40
addaleax added a commit that referenced this pull request Jun 3, 2017
Under very specific circumstances the `http` implementation
could be brought to crash, because the Agent did not re-assign
the async id field properly after setting up a socket for reuse.

Fixes: #13325
PR-URL: #13348
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Andreas Madsen <amwebdk@gmail.com>
jasnell pushed a commit that referenced this pull request Jun 5, 2017
Under very specific circumstances the `http` implementation
could be brought to crash, because the Agent did not re-assign
the async id field properly after setting up a socket for reuse.

Fixes: #13325
PR-URL: #13348
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Andreas Madsen <amwebdk@gmail.com>
@jasnell jasnell mentioned this pull request Jun 5, 2017
@gibfahn gibfahn mentioned this pull request Jun 15, 2017
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
async_hooks Issues and PRs related to the async hooks subsystem. http Issues or PRs related to the http subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants