standardizing Error.stack or equivalent

Mark S. Miller erights at google.com
Thu Jul 23 19:59:53 UTC 2015


On Thu, Mar 27, 2014 at 3:28 PM, Mark S. Miller <erights at google.com> wrote:

> [+google-caja-discuss]
>
> Cool. I will fix the debug.js adaptor
> a) to fix the bug Boris reported,
> b) to map the FF nested format to the v8 nested format, and
> c) to preserve this information from the v8 API so that it appears
> correctly on v8 as well.
> This will require extending the Causeway stack trace format (an encoding
> of stack trace info into JSON), which looks like it should be
> straightforward. Thanks!
>
> Once extended in this way, would it be useful to standardize the Causeway
> stack trace representation, so others can avoid trying to parse the stack
> trace strings with regexps?
>


This was issue https://github.com/google/caja/issues/1906 which we just
closed with https://codereview.appspot.com/256790043/ . See the definition
of the Extended Causeway JSON stacktrace format starting at <
https://github.com/google/caja/blob/master/src/com/google/caja/ses/debug.js#L36>,
line 36.

Due to <https://code.google.com/p/v8/issues/detail?id=4268>, we need to do
some unreliable scraping even on v8 to recover this info. This is open to
attack. As it says at <
https://github.com/google/caja/blob/master/src/com/google/caja/ses/debug.js#L184
>:

There are a variety of user-triggered
conditions that can cause this scraping to fail, such as a
methodName that contains an "(" or "@" character.


Standardizing on the JSON for the Extended Causeway Stacktrace would make
this necessarily-unreliable scraping unnecessary on all future std JS
platforms.




>
> On Thu, Mar 27, 2014 at 3:09 PM, Christian Plesner Hansen <c7n at p5r.org>
> wrote:
>
>>  Yes: https://code.google.com/p/v8/wiki/JavaScriptStackTraceApi
>>
>>
>> c
>>
>> On Thu, Mar 27, 2014, at 03:06 PM, Mark Miller wrote:
>>
>> I wasn't aware that v8 does that. Is this format documented anywhere?
>>
>>
>> On Thu, Mar 27, 2014 at 2:23 PM, Christian Plesner Hansen <c7n at p5r.org>
>> wrote:
>>
>>
>> >     js> try { eval("eval('FAIL')"); } catch (x) { print(x.stack); }
>>  >     @typein line 2 > eval line 1 > eval:1:1
>>  >     @typein line 2 > eval:1:1
>>  >     @typein:2:7
>>
>> I'm unclear on what the problem is with nested evals -- you get
>>  essentially the same information from v8:
>>
>>  js> try { eval("eval('FAIL')"); } catch (x) { console.log(x.stack); }
>>  ReferenceError: FAIL is not defined
>>      at eval (eval at <anonymous> (eval at <anonymous> (repl:1:7)),
>>      <anonymous>:1:1)
>>      at eval (eval at <anonymous> (repl:1:7), <anonymous>:1:1)
>>      at repl:1:7
>>
>>
>>
>>  c
>>  _______________________________________________
>>  es-discuss mailing list
>>  es-discuss at mozilla.org
>>  https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>>
>>
>> --
>> Text by me above is hereby placed in the public domain
>>
>>   Cheers,
>>   --MarkM
>>  *_______________________________________________*
>> 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
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150723/4c872172/attachment-0001.html>


More information about the es-discuss mailing list