github at esdiscuss.org (2013-07-12T02:27:37.717Z)
On Mon, Jun 17, 2013 at 11:33 AM, Chad Austin <chad at imvu.com> wrote: > 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 hope we can stitch together stack traces in JS as well. This is desperately needed to make asynchronous and distributed code practical, more on a par with local synchronous code. Please follow the Causeway links in the email you're responding to. The Causeway work was done in the context of event-loops and promises, but not generators. We should explore how to extend its stack stitching approach to include generators. > 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?) Yes. Fortunately on Chrome we can effectively [remove it](https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js). > , 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. The built-in window.onerror can have/use the rights amplification powers of the getStack or @stacktrace in my previous message. This would not violate any security constraint, since untrusted scripts within a frame are denied direct access to their true window and global scope anyway. > 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! You are very welcome! Always nice to hear.
On Mon, Jun 17, 2013 at 11:33 AM, Chad Austin <chad at imvu.com> wrote: > 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 hope we can stitch together stack traces in JS as well. This is desperately needed to make asynchronous and distributed code practical, more on a par with local synchronous code. Please follow the Causeway links in the email you're responding to. The Causeway work was done in the context of event-loops and promises, but not generators. We should explore how to extend its stack stitching approach to include generators. > > 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?) > Yes. Fortunately on Chrome we can effectively remove it < https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js >. > , 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. > The built-in window.onerror can have/use the rights amplification powers of the getStack or @stacktrace in my previous message. This would not violate any security constraint, since untrusted scripts within a frame are denied direct access to their true window and global scope anyway. > > 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! > You are very welcome! Always nice to hear. > > > > On Sat, Jun 15, 2013 at 6:56 PM, Mark S. Miller <erights at google.com>wrote: > >> On Sat, Jun 15, 2013 at 10:17 AM, David Bruant <bruant.d at 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 at 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 at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > Chad Austin > Technical Director, IMVU > http://www.imvu.com/members/Chad/ > > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130618/4669a08c/attachment-0001.html>