`free` operator

Rick Waldron waldron.rick at gmail.com
Fri Oct 26 12:24:53 PDT 2012


On Fri, Oct 26, 2012 at 2:58 PM, Isaac Schlueter <i at izs.me> wrote:

> So, yes, you can certainly use debugging tools to find which objects
> are leaking.  But, there are times when you have a program where
> something is leaking, and you read through the code, and see that
> there is no possible way that it could be leaking (but it is, as
> reality sometimes stubbornly refuses to be told what to do.)
>
> Use-after-free bugs are not great, but they are relatively easy to
> track down.  And, in general, a program that crashes when it does
> something wrong, is handling it exactly right.  Slowly leaking memory
> is much harder to diagnose, and usually much harder to correct.
>
> We've got some band-aids in place in the node http.js file to prevent
> parser leaks.  A more forcible free() method would have made it much
> easier.  The long-term solution is to rewrite the program so that it's
> not so badly architected, but as is so often the case, we didn't
> realize the architectural mistakes until we had made them, and fixing
> them is quite costly.  (Node's http implementation will get a massive
> refactor in 0.12.)
>
> Yehuda's "action at a distance" complaint is definitely a valid
> concern.  However, note that an object can't be freed unless you have
> a reference to the object.  Thus, any code that would set my reference
> to undefined could only do so if it was also capable of mutating the
> object in any other way (adding/removing properties, etc.)
>
> So, we already have this:
>
> function () {
> // acquire a ref from some external code
> // no way of knowing what else is sharing this object
> var x = func()
> x.foo = 'bar'
> // other code...
> doAnotherThing()
> // not guaranteed!
> assert(x.foo === 'bar')
> }
>
> Whenever you have a reference to an object that is shared with some
> other code, there's the potential for action at a distance.  The
> proposal here is to make that action a bit more powerful.
>
> I don't agree that it's necessarily a problem in production.  We free
> objects in other languages all the time.
>

Isaac, Would you be interested in or willing to create an experimental
prototype (ie. behind a flag) in node? I think you're in a particularly
strong position to make a case for the proposal :)



Rick




>
>
> On Fri, Oct 26, 2012 at 5:11 PM, Patrick Mueller <pmuellr at gmail.com>
> wrote:
> > On Fri, Oct 26, 2012 at 11:51 AM, John J Barton
> > <johnjbarton at johnjbarton.com> wrote:
> >>
> >> Debugging tools lag other tools in part because test-cases or
> >> use-models are hard not readily available.
> >
> >
> > But the only debugging tools we really have are proprietary low-level
> APIs
> > (eg, V8 debug stuff), and some existing debug ui frameworks (eg, Web
> > Inspector).  The barrier is so, so high for this stuff.  Compared to a
> > number of other environments where the barrier is not so high.  Eg, in
> C, if
> > you're debugging memory issues, switching to using a debug malloc library
> > isn't a huge barrier.
> >
> > It would be nice to lower the barrier, expose some "debug" stuff in JS.
> > Implying that I want "debug APIs" available in JS, and I want to write my
> > debug helpers in JS.
> >
> > V8's --expose-debug-as (or whatever) trick is a step in the right
> direction.
> > It would be nice to have some commonality here, so I don't have to write
> one
> > set of debug helpers for V8, another for JSC, another for *Monkey, etc.
> >
> >>
> >> The js-tools group would be ideal for more discussions of these
> >> issues: https://groups.google.com/forum/?fromgroups=#!forum/js-tools
> >
> >
> > Ah, nice.  I'll stop pestering here, and start pestering there.  :-)
> >
> > --
> > Patrick Mueller
> > http://muellerware.org
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121026/7426d97f/attachment.html>


More information about the es-discuss mailing list