`free` operator

John J Barton johnjbarton at johnjbarton.com
Fri Oct 26 12:34:11 PDT 2012


On Fri, Oct 26, 2012 at 11:58 AM, 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.
...
>
> 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')

FWIW, Querypoint debugging will be able to tell you "where was x.foo changed?".

> }
>
> Whenever you have a reference to an object that is shared with some
> other code, there's the potential for action at a distance.

Seems like other questions we'd like to answer include "where was the
object refed by 'x' defined?" "Where are other references to that
object taken?" "Where was any property of 'x' written?" These seem
feasible.

jjb


More information about the es-discuss mailing list