On Thu, Oct 25, 2012 at 10:14 PM, Shawn Steele <[email protected]> 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? _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
