Created
June 24, 2011 11:34
-
-
Save richardms/1044613 to your computer and use it in GitHub Desktop.
Possible memory leak in node-proxy
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
// Run with: | |
// node --trace-gc proxy_memleak.js | |
var Proxy = require("node-proxy"), | |
fs = require('fs'), | |
util = require("util") ; | |
var count = 100000 ; | |
var handlerFactory = function () { | |
// Load something big: | |
var data = fs.readFileSync("/bin/ls") ; | |
return { | |
get: function (receiver, name) { | |
if (name === "length") { | |
return data.length ; | |
} | |
}, | |
getOwnPropertyDescriptor: function(name) { | |
var desc = undefined ; | |
if (name === "length") { | |
return Object.getOwnPropertyDescriptor(data, name) ; | |
} | |
return desc; | |
}, | |
getOwnPropertyNames: function() { | |
return ["length"] ; | |
}, | |
defineProperty: function(name, propertyDescriptor) { | |
}, | |
"delete": function(name) { | |
}, | |
fix: function() { | |
// As long as this.obj is not frozen, the proxy won't allow itself to be fixed | |
return undefined; // will cause a TypeError to be thrown | |
} | |
} ; | |
} ; | |
while (count > 0) { | |
var proxy = Proxy.create(handlerFactory()) ; | |
if ((count % 1000) === 0) { | |
util.debug("length: "+proxy.length+" "+JSON.stringify(process.memoryUsage())) ; | |
} | |
count -= 1 ; | |
} |
Author
richardms
commented
Jun 24, 2011
via email
Thanks for getting in touch.
Line 13 is the key to my use case - I find that any object I create (or
indeed pass in and use) to the closure is never garbage collected, even
after the proxy itself should have disappeared. So line 13 is there to make
the closure sizeable and hence the memory leak easier to spot.
So, I'm not sure whether the proxy is not being a GC victim, or the
associated handler object has an incorrect reference count or a hidden
reference hanging around somewhere. Any thoughts?
I tried a scenario in this gist where I directly released the reference from the large object, but it did not have a mitigating effect on the heap size.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment