Hi Mark,
I'm the author of IMVU's task system, which is very similar to what Bruno
describes except with Python Futures and Python generators. Python
provides stack traces as a linked list of activation records from the
thrower to the catcher. On the other hand, Error().stack in most
JavaScript implementations returns a complete stack trace all the way up to
the main event loop. Python's linked list stack traces allows stitching
them together so that if async generator A yields to async generator B, and
B throws, both A and B can be made to appear in the stack together.
Finally, and this is key, Python attaches stack traces to the act of
_throwing_ and not to the exception object itself.
I'm not familiar with the security or encapsulation issues with
Error().stack (is it that bad if Chrome and Firefox appear to support the
.stack property?), but I would like to express my support for being able to
stitch together stack traces on the open web so that if something goes
wrong developers have a shot at diagnosing what happened. Native
application developers have dozens of fantastic options for phone-home
crash reporting, but on the web the best you can hope for is that your
customer's browser supports Error#stack and window.onerror provides the
thrown exception.
Thanks,
Chad
p.s. E was hugely influential in my thinking about concurrency and led me
to build the task system at IMVU in the first place, so thanks!
On Sat, Jun 15, 2013 at 6:56 PM, Mark S. Miller <erig...@google.com> wrote:
> On Sat, Jun 15, 2013 at 10:17 AM, David Bruant <bruan...@gmail.com> wrote:
>
>> Le 15/06/2013 11:18, Bruno Jouhier a écrit :
>>
>> A generator object represents a computation which has been suspended. We
>>> have an API to resume this computation (next/throw). What's missing is an
>>> API to get information about this suspended computation (which function,
>>> where in the source).
>>>
>> As an aside, note that we already have this sort of problem today with
>> event loop turns.
>>
>> function schedule(){
>> if(Math.random() < 0.5)
>> throw new Error('whatever');
>> else
>> setTimeout(schedule, Math.random()*100);
>> }
>>
>> setTimeout(schedule, (Math.random()*100) |0)
>> setTimeout(schedule, (Math.random()*100) |0)
>>
>> There is no way to know how many scheduling happened before the first
>> thrown error, nor whether the error comes from the first or second
>> scheduling originally. And that's a dummy 5-line example. It gets worse
>> when you have a sequence of different events (or promise resolutions)
>> called at different times, adding other listeners, etc.
>> Q solves that with long stack traces [1] (only for promises I believe).
>> It might be worth looking into it.
>>
>>
>> Back to your problem, I worry that this kind of information (a call to
>> get the stack trace of where the generator last yielding with line number)
>> may partially break encapsulation which wouldn't be good for security.
>> I'm thinking of something like:
>>
>> (exports => {
>> var someCrucialInfo = // boolean
>>
>> exports.bla = function*(){
>> if(someCrucialInfo){
>> doX();
>> yield 27;
>> }
>> else{
>> doY();
>> yield 27;
>> }
>> }
>> })(this);
>>
>> var v = this.bla();
>> var l = getLastBlaYieldLine(bla);
>> // given l, the encapsulated value of someCrucialInfo can be inferred
>>
>> cc'ing MarkM to get his eyes on it as I don't feel qualified to assess
>> the gravity.
>>
>
> Thanks for calling my attention to this thread. Generators and multiple
> turns aside (see below), we've been over the security issue before but a
> recap is useful. The stack trace information cannot be publicly accessible
> from the Error object because it violates encapsulation. (Historical note:
> When E entered its first security review, it had this vulnerability. Thanks
> to David Wagner for catching it.) Instead, some sort of rights
> amplification is required. One possible interface is a privileged function,
> like the getStack function at <
> https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#221>,
> where
>
> getStack(err) returns the stacktrace. If you don't have the getStack
> function, you can't get the stacktrace. getStack is implemented using a
> WeakMap associating Errors with stacktraces.
>
> Another approach, if <
> http://wiki.ecmascript.org/doku.php?id=strawman:relationships> are
> adopted in ES7, is to have a relationship associating Error objects with
> stacktraces. The full read/write relationship would be internal to the
> implementation, but a relationship representing a readonly facet of that
> relationship, say @stacktrace, could be made available in the same
> privileged manner as getStack above. Then
>
> err@stacktrace would return the same stacktrace that getStack(err) would
> return above.
>
> If relationships don't happen in ES7 (it's too late for ES6) and private
> symbols do, then @stacktrace could be a private symbol.
>
>
>
> Multiple turn distributed debugging is indeed the next frontier, and one
> that will become ever more urgent as promises continue to catch on. I
> participated in a cool project, Causeway, that explored some of this
> territory well
> http://www.hpl.hp.com/techreports/2009/HPL-2009-78.html
> https://code.google.com/p/causeway/
>
> Although the project has since been abandoned, its trace log format is a
> good place to start, in order to be able to support something like this in
> the future:
> http://wiki.erights.org/wiki/Causeway_Platform_Developer
> http://wiki.erights.org/wiki/Causeway_Platform_Developer:_Ajax
> http://wiki.erights.org/wiki/Causeway_Platform_Developer:_Promises
>
>
> https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js
> also provides some support for the Causeway log format. See getCWStack.
>
> See also
> http://crpit.com/confpapers/CRPITV135Murray.pdf and
> http://infoscience.epfl.ch/record/181543/files/EPFL_TH5533.pdf
> for other interesting approaches to extended debugging
>
>
> As for generators specifically, it seems to me that whatever rights
> amplification operation one applies to an Error object to get a stack
> trace, one should also be able to apply to a generator instance to get a
> 1-level stacktrace showing where it is currently suspended.
>
>
>
>> oh... and we have the source code of functions by default with
>> Function#toString.
>> This sort of inference can happen in regular error stack traces too, but
>> requires for a function to throw which happens only if it's supposed to,
>> not at the caller's will.
>> Though I realize now that anyone holding a reference to a generator can
>> force an error being thrown and, if uncaught, it generates a stack trace
>> leaking the line number even without the API you're asking for (but that
>> would work only once)
>>
>>
>> I see this as being similar to asking for a portable "stack" property in
>>> Error objects. I don't know if it is actually mandated by ES6 but it looks
>>> like all major JS engines support it now.
>>>
>> I believe the state of TC39 on Error#stack can be found at
>> http://wiki.ecmascript.org/**doku.php?id=strawman:error_**stack<http://wiki.ecmascript.org/doku.php?id=strawman:error_stack>
>>
>> David
>>
>> [1]
>> https://github.com/kriskowal/**q#long-stack-traces<https://github.com/kriskowal/q#long-stack-traces>
>>
>
>
>
> --
> Cheers,
> --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
Chad Austin
Technical Director, IMVU
http://www.imvu.com/members/Chad/
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
