-
-
Notifications
You must be signed in to change notification settings - Fork 31.4k
lib: fix cluster handle leak #3510
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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 <info@bnoordhuis.nl>
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. |
Landed in da21dba |
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 <info@bnoordhuis.nl>
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 <info@bnoordhuis.nl>
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