On Fri, Oct 26, 2012 at 1:19 PM, Yehuda Katz <wyc...@gmail.com> wrote:
> An optimal debugger would show the textual location in the source code where
> live references to a particular object were created.
A concrete example would ensure that we imagine the same things, but for
var foo = { ref: obj }
var obj2 = obj
we see that recording initializers and assignments using the
identifier 'obj' will give the raw material for this tool. These
traces must then be filtered to the ones where 'obj' references the
particular object Isaac is tracing. That is the same procedure as
Querypoint's lastChange, but with different AST nodes being traced.
> Optimally, it would be
> possible to get the references during debug mode via the "tooltip" that
> comes up when hovering over a variable.
Yes, though my current implementation drives a side panel with
mouseover-ish rather than tooltips to allow a more complete UI.
>
> Isaac could then solve his problem trivially by adding a debugger where he
> would have called free and look at what other places in the source are still
> holding references.
I hope for "trivially" but I'll settle for "with relative ease".
jjb
>
> On Fri, Oct 26, 2012 at 12:34 PM, John J Barton
> <johnjbar...@johnjbarton.com> wrote:
>>
>> On Fri, Oct 26, 2012 at 11:58 AM, Isaac Schlueter <i...@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
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> --
> Yehuda Katz
> (ph) 718.877.1325
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
