Finding memory leaks in a moderately complicated program written in a
statically typed language is hard, change to a dynamic language,
JIT'ed code, garbage collection, and closures -- and well, damn, it's
hard.
You're simply not going to be able to use a static analyzer pass on
JavaScript to identify all "memory leak".
Keep in mind that what you're generally chasing down in JavaScript is
not actually a "memory leak", but rather a resource leak. In other
words, you're holding onto an object for longer than what you had
anticipated. A lot of times because of a function closure is holding
the resources in its parents scope, and you forgot about that part.
Ugh.
You picked this language because it had functions as first class and
supported closures, and now it's getting in your way!
The best thing you can do to combat resource leaks is to write cleaner
code. Start by avoiding closures, and maybe use a control flow library
that makes that part easier for you. If you can think more in a stack
based way, that is passing your state to the functions, you know
exactly how much state you're carrying with you. And hopefully you
will stop carrying all that extra state around.
As an aside I think Node's best control flow library, is our flow
control abstraction -- Streams.
That being said, let's say you have an application in production today
and you want to track down a resource leak, you want to find out what
it is exactly you're keeping around. I've had to do this a lot [1]. So
have a lot of my colleagues at Joyent, and they have written a bunch
of tooling around it to make it easier [2] [3]. It's all open source
[4]. And the tooling works with artifacts that are generated on Linux
as well [5].
It's all done with postmortem analysis, that is using a core file
after the fact, which is ideal because if you knew you were going to
have a problem before going into production you probably just wouldn't
have gone into production before fixing the problem. The benefit here
is that if node runs out of memory it will generate a core file, and
you can debug that in place and figure out what went wrong.
There are other solutions that people use, things like the module
heapdump [6] for example, this requires though that you knew in
advance you were having a memory problem, and could add another
module, and that you invoked a heapdump in time before the process
died. Once that's done you can load that file into chrome's inspector
tools to browse the heap. That can be painful if the file is
particularly large.
Hopefully some of this information helps, let me know if there's
anything else you need.
[1]
http://www.joyent.com/blog/walmart-node-js-memory-leak
[2]
http://www.joyent.com/developers/node/debug
[3]
http://www.joyent.com/developers/node/debug/mdb
[4]
https://github.com/joyent/illumos-joyent
[5]
http://www.joyent.com/blog/mdb-and-linux
[6]
http://npmjs.org/package/heapdump
> --
> --
> Job Board:
http://jobs.nodejs.org/
> Posting guidelines:
>
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to
nod...@googlegroups.com
> To unsubscribe from this group, send email to
>
nodejs+un...@googlegroups.com
> For more options, visit this group at
>
http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
nodejs+un...@googlegroups.com.
> For more options, visit
https://groups.google.com/d/optout.