`free` operator

Andrew Paprocki andrew at ishiboo.com
Thu Oct 25 20:13:12 PDT 2012

On Thu, Oct 25, 2012 at 10:14 PM, Shawn Steele
<Shawn.Steele at microsoft.com> wrote:
>> On the contrary, "TypeError: Cannot read property 'prop' of undefined", with a stack trace, is WAY easier to track down than "The RSS on my server gradually rises, until the operating system kills it, which happens about every 4 hours."
> I'm not so sure.  Now you know where you're using it that you didn't think you were, but you've now got something freeing it that's not supposed to.  So you might have to check each of those "free"s to see where they weren't supposed to free, possibly without much context at the other end.  You've traded one problem for a different one.

I can offer that we do this pretty commonly with certain native
objects wrapped into JS and that it is useful, albeit trading
problems, as you say. My personal observation is that it is much
easier for a large body of JS programmers to grasp this
"use-after-free" class of bugs than tracking down GC related issues
such as a closure capturing a scope to which someone unknowingly added
a variable keeping a whole tree of things alive.

I would love it if tools could to a better job at illustrating why
objects are kept alive, though. There is no desire to standardize JS
bytecode or anything of that nature, but perhaps there is room to
standardize some kind of serialized GC heap view akin to a 'core' file
for debugging purposes so that tool writers have an easier job?

More information about the es-discuss mailing list