-
Notifications
You must be signed in to change notification settings - Fork 30.4k
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
lib: fix cluster handle leak #3510
Conversation
Meh. Relevant test failure on Windows. Back to the drawing board for a bit... |
3229ac8
to
0291472
Compare
OK, all squashed into a single commit and working on all platforms now. Results of the added test in Node 4.2.1:
With this patch, no assertion is thrown. |
|
||
process.on('message', function listener() { | ||
server.close(function() { | ||
process.exit(); |
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.
Is the process.exit necessary?
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.
If I comment out process.exit()
and leave the rest of the test as is, the test never terminates.
Change itself LGTM but the test can probably be a little tighter. |
I made some changes based on @bnoordhuis comments and also renamed the test and added an explanatory comment. New CI: https://ci.nodejs.org/job/node-test-pull-request/613/ |
You should be able to get rid of the diff --git a/test/parallel/test-cluster-shared-leak.js b/test/parallel/test-cluster-shared-leak.js
index 680709f..1cabe6f 100644
--- a/test/parallel/test-cluster-shared-leak.js
+++ b/test/parallel/test-cluster-shared-leak.js
@@ -9,23 +9,25 @@ const cluster = require('cluster');
cluster.schedulingPolicy = cluster.SCHED_NONE;
if (cluster.isMaster) {
- var worker1, worker2;
+ var conn, worker1, worker2;
worker1 = cluster.fork();
worker1.on('message', common.mustCall(function() {
worker2 = cluster.fork();
- const c = net.connect(common.PORT, common.mustCall(function() {
- c.unref();
+ conn = net.connect(common.PORT, common.mustCall(function() {
worker1.send('die');
worker2.send('die');
}));
- c.on('error', function(e) {
- // ECONNRESET is OK
- if (e.code !== 'ECONNRESET')
- throw e;
- });
}));
+ cluster.on('exit', function(worker, exitCode, signalCode) {
+ assert(worker === worker1 || worker === worker2);
+ assert.strictEqual(exitCode, 0);
+ assert.strictEqual(signalCode, null);
+ if (Object.keys(cluster.workers).length === 0)
+ conn.destroy();
+ });
+
return;
}
@@ -40,6 +42,6 @@ server.listen(common.PORT, function() {
process.on('message', function(msg) {
if (msg !== 'die') return;
server.close(function() {
- process.exit();
+ setImmediate(() => process.disconnect());
});
}); Your test passes locally for me however, with and without the change to lib/cluster.js and with or without my changes to the test. |
It is possible to cause a resource leak in SharedHandle if a worker is added after all other workers have been removed. This commit fixes the leak. Fixes: nodejs#2510 PR-URL: nodejs#3510
@bnoordhuis You must be running Linux. I commented out the new line in Every single operating system triggered the error on all builds except Linux. It did trip up CentOS 6 and Fedora 22. It could be that Linux is affected, but not reliably affected. Or it could be that only those Linux distro/versions are affected. It makes sense to me that the problem could be OS-dependent as the test needs to turn off round-robin scheduling and rely on system scheduling. (Otherwise, it doesn't fail for anything.) |
Interesting. I run Linux - FC22 actually - but it sounds plausible that it's a platform-specific issue. LGTM if you steal my changes. |
It is possible to cause a resource leak in SharedHandle. This commit fixes the leak. Fixes: nodejs#2510 PR-URL: nodejs#3510 Reviewed-By: Ben Noordhuis <[email protected]>
With your changes, I still get a reliable (expected) test failure with Node 4.2.1 on OS X and reliable success with the change to And one (hopefully final) CI: https://ci.nodejs.org/job/node-test-pull-request/617/ |
@bnoordhuis With your changes to the test, everything passes except Windows. But Windows is not reporting the Resource Leak issue anymore. It's instead reporting this:
I'm inclined to put back the error handler I had in there that swallowed |
I think so. Probably best to put the error listener back. |
Error listener is back. CI: https://ci.nodejs.org/job/node-test-pull-request/618/ |
A few unrelated test failures on CI, looks good otherwise. Thanks! |
I'll land this in 12-24 hours unless someone objects. |
It is possible to cause a resource leak in SharedHandle. This commit fixes the leak. Fixes: #2510 PR-URL: #3510 Reviewed-By: Ben Noordhuis <[email protected]>
Landed in da21dba |
It is possible to cause a resource leak in SharedHandle. This commit fixes the leak. Fixes: #2510 PR-URL: #3510 Reviewed-By: Ben Noordhuis <[email protected]>
Landed in v4.x-staging in e4417a1 |
It is possible to cause a resource leak in SharedHandle. This commit fixes the leak. Fixes: nodejs#2510 PR-URL: nodejs#3510 Reviewed-By: Ben Noordhuis <[email protected]>
It is possible to cause a resource leak in SharedHandle. This commit fixes the leak. Fixes: #2510 PR-URL: #3510 Reviewed-By: Ben Noordhuis <[email protected]>
It looks like at least v0.12 has this same issue and needs this fix too. I am not sure about v0.10 yet. |
It is possible to cause a resource leak in SharedHandle. This commit fixes the leak. Fixes: nodejs#2510 PR-URL: nodejs#3510 Reviewed-By: Ben Noordhuis <[email protected]>
It is possible to cause a resource leak in SharedHandle
if a worker is. This commit fixes theadded after all other workers have been removed
leak.
Fixes: #2510