-
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
async_hooks,http: fix socket reuse with Agent #13348
Conversation
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
} | ||
}, common.mustCall((res) => { | ||
const asyncId = res.socket[async_id_symbol]; | ||
assert.ok(asyncId > 0, `${asyncId} > 0`); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 Agent
s could use it.
Something like Socket.prototype._prepareForReuse()
or _recycle
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed
There was a problem hiding this comment.
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.
I don't know why but my intuition was to do this somewhere in a
Socket
method. Maybe move both lines to aSocket
method so otherAgent
s could use it. Something likeSocket.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()
.
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.
assert.strictEqual(r1.socket, socket); | ||
|
||
res.on('data', common.mustCallAtLeast(() => {})); | ||
res.on('end', common.mustCall(() => { |
There was a problem hiding this comment.
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)
There was a problem hiding this 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.
res.on('data', common.mustCallAtLeast(() => {})); | ||
res.on('end', common.mustCall(() => { | ||
// setImmediate() to give the agent time to register the freed socket. | ||
setImmediate(common.mustCall(() => { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. :)
/cc @nodejs/testing for reviews of the test file |
Landed in 3e02636 |
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>
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>
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), orvcbuild test
(Windows) passesAffected core subsystem(s)
http, async_hooks