Re: Error stack strawman

[Mark S. Miller]

On Thu, Feb 25, 2016 at 6:45 PM, Gary Guo  wrote:

> Things became more complicated when considering async & generators. For
> async calls as mentioned before somewhere in the thread, only Firefox
> Nightly build includes histories of the frame, while all other browsers
> don't. It could be useful to include that in stack trace, but it will then
> be a special case to a general rule, so not all functions are treated as
> the same. Also, including this information can be costly. Similar reasoning
> about usefulness can be extended to generators & async functions. Shall we
> include a copy of history frames at the time the function is called? (If we
> use FF's SavedFrame format, then in this case both `parent` and
> `asyncParent` will be set) Again, this will be costly as well. In these two
> cases, it could be useful to developers if these information are available,
> but generally these will be costly to collect. Making these optional can be
> a choice, by simply not including unsupported fields in the returned
> object. I suppose `isTailCall` can be made optional as well.
>

All important issues. My current stance:

  * We should separate the issue of obtaining the shallow synchronous
within-a-turn stacks from the gathering of multiple of these together into
deep stacks or graphs of asynchronous causality.

  * The getStack and getStackString apis, and the corresponding normative
optional deletable Error.prototype.stack accessor, should only provide
shallow within-turn stacks.

In thinking about how Causeway stitches these separate shallow synchronous
stacks into an overall picture of asynchronous causality, including deep
stacks, I think the next steps are something like:

  * The stack object format should contain one additional thing -- a turn
identifier, identifying the turn that stack occurred in. To avoid leaking
unnecessary implementation details, say that this turn identifier is a
large random number.

  * There be some way to declare that a certain scope of activity (realm?)
is to be instrumented, i.e., that certain significant events generate
notifications to some kind of logging apparatus. This issue already arises
with onerror and unhandled rejection notifications.

  * When instrumented, an action in one turn that schedules something to
happen in another turn also emits a log-notification containing:

* the stack of the scheduling action within the scheduling turn,
including the turn identifier of the scheduling turn.
* the turn identifier of the scheduled turn.

When the scheduling turn and the scheduled turn both happen in the same
vat, then stitching the shallow stacks together into a deep stack creates
exactly the kinds of deep stack we see on FF. However, I purposely phrased
that last bullet so that it also applies to inter-vat causality. For
example, if instrumented worker A does a postMessage to instrumented worker
B, the postMessage event in worker A logs, in A,

  * the stack in A where A did the postMessage, including the identifier of
the A turn in which this happened.
  * the identifier of the turn in worker B where this message will be
processed.

There is much more to be said and explored, but I think that would be a
start. It naturally breaks up into two separable proposals -- the first two
bullets and the rest.

-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Error stack strawman

[Gary Guo]

Things became more complicated when considering async & generators.

For async calls as mentioned before somewhere in the thread, only Firefox 
Nightly build includes histories of the frame, while all other browsers don't. 
It could be useful to include that in stack trace, but it will then be a 
special case to a general rule, so not all functions are treated as the same. 
Also, including this information can be costly.

Similar reasoning about usefulness can be extended to generators & async 
functions. Shall we include a copy of history frames at the time the function 
is called? (If we use FF's SavedFrame format, then in this case both `parent` 
and `asyncParent` will be set) Again, this will be costly as well.

In these two cases, it could be useful to developers if these information are 
available, but generally these will be costly to collect. Making these optional 
can be a choice, by simply not including unsupported fields in the returned 
object. I suppose `isTailCall` can be made optional as well.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Boris Zbarsky]

On 2/24/16 6:59 PM, Steve Fink wrote:

(Or at least, that's my understanding of what is going on. I'm not sure
if that stuff is used for Error.stack yet.)


It is.  See https://bugzilla.mozilla.org/show_bug.cgi?id=1038238

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Steve Fink]

On 02/24/2016 01:30 PM, Mark S. Miller wrote:
[2] This solves only one of the cross-realm issue with stacks. It does 
nothing to address worries about cross-realm stacks.




We do have code in FF that handles cross-realm stacks, or at least a 
close moral equivalent to them. The stacks are stored internally as 
objects, and each frame records where it comes from, so a user will only 
see frames that it has privileges for. Obviously, once you convert to a 
string, you're past the point of control.


(Or at least, that's my understanding of what is going on. I'm not sure 
if that stuff is used for Error.stack yet.)


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Mark S. Miller]

On Wed, Feb 24, 2016 at 2:37 PM, Boris Zbarsky  wrote:

> On 2/24/16 5:35 PM, Boris Zbarsky wrote:
>
>> Clearly this Just
>> Works with a value property, across all browsers at that point, so we
>> made it work with the accessor too.
>>
>
> Oh, and we made it work the way [Replaceable] stuff on window works: the
> setter defines a value property on the object which thereafter shadows the
> prototype's getter.



It is ugly so I would hope we don't need to preserve it. But if it is
needed for web compat, as a normative-optional deletable accessor, I have
no fundamental objection.


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Boris Zbarsky]

On 2/24/16 5:35 PM, Boris Zbarsky wrote:

Clearly this Just
Works with a value property, across all browsers at that point, so we
made it work with the accessor too.


Oh, and we made it work the way [Replaceable] stuff on window works: the 
setter defines a value property on the object which thereafter shadows 
the prototype's getter.


-Boris

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Boris Zbarsky]

On 2/24/16 4:30 PM, Mark S. Miller wrote:

[1] For some reason the FF stack accessor has both getter and setter. I
don't see any reason for a setter.


We ran into code "in the wild" (more precisely, within our own test 
suite infrastructure, but we have no reason to believe this would not 
happen in the wild) where people were reading error.stack, doing some 
processing on it, and then setting error.stack on that same error, and 
expecting error.stack to be that thing after that.  Clearly this Just 
Works with a value property, across all browsers at that point, so we 
made it work with the accessor too.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Mark S. Miller]

Huh, weird. From the discussions that led to <
https://github.com/claudepache/es-regexp-legacy-static-properties> being
proposed and the discussion on that issue, for me to take a consistent
position, I must sadly concede the following:

We allowed a grossly leaky api (the RegExp statics, which leak non-local
information from RegExp instances )
to be proposed for standardization as "normative optional", i.e., Annex B,
and deletable. This way, and environment that deletes it still leaves a
conforming system in its wake. Many people think they want error.stack
because it seems to do something on all the browsers -- though their
behaviors are tremendously different from each other. Nevertheless,
whatever behavior we specify for getStackString, we could likewise spec a
normative optional and deletable Error.prototype.stack accessor property,
like Firefox's[1]. As with makeWeakRef and the leaky RegExp statics, we
could specify the getter of this accessor only to work on Error objects
from the same realm[2]. Since errors inherit from the Error.prototype of
their own realm anyway, this does not impede normal usage. We need to
impose the same restriction on getStack and getStackString anyway, for the
same reasons.

FF demonstrates that it is already web compatible to provide error.stack
only by providing a deletable Error.prototype.stack accessor.

On FF, my polyfill <
https://github.com/tvcutsem/es-lab/blob/master/src/ses/debug.js> makes use
of the fact that Error.prototype.stack is an accessor, both to censor the
property on initialization, be deleting it, and to reserve for itself the
ability to inspect stacks, by utilizing the getter it took away. That is
how it implements getStack without providing ambient access to the stack.


[1] For some reason the FF stack accessor has both getter and setter. I
don't see any reason for a setter.
[2] This solves only one of the cross-realm issue with stacks. It does
nothing to address worries about cross-realm stacks.



On Wed, Feb 24, 2016 at 12:37 PM, Mark S. Miller  wrote:

> On Wed, Feb 24, 2016 at 11:40 AM, Steve Fink  wrote:
>
>> On 02/19/2016 01:26 AM, Andreas Rossberg wrote:
>>
>> On 19 February 2016 at 03:13, Gary Guo  wrote:
>>
>> If we are not going to indicate tail call some way, debugging might be
>>> extremely difficult, and the stack result might be making no sense at all.
>>>
>>
>> A tail call is a jump. Just like other jumps, you shouldn't expect their
>> history to be visible in the continuation (which is what a stack trace
>> represents). I agree that JS programmers might be surprised, and will have
>> to relearn what they know. But wrt to debugging the situation is the same
>> as for loops: you can't inspect their history either. (And functional
>> programmers in fact see loops as just an ugly way to express self tail
>> recursion. :) )
>>
>>
>> To be even more pedantic: the stack trace isn't "the" continuation, it is
>> one possible continuation. Other continuations are possible if you throw an
>> exception. I guess you could say the stack trace plus the code allows you
>> to statically derive the full set of possible continuations.
>>
>> But I agree that it's worthwhile to remember the difference, since what
>> is being requested for stacks really *is* a history, not a continuation.
>> For example, it is desireable to encode "long stacks" or "async stacks" or
>> whatever they're being called these days, where eg for an event handler you
>> get the stack trace at the point the handler was installed. That is not a
>> continuation, that is history. I would be very wary of mandating that full
>> history be preserved, since it's easy for it to prevent optimizations or
>> inadvertently leak details of the underlying implementation (tail calls,
>> inlining, captured environments).
>>
>> Does it work to specify something like "if and only if the information is
>> available, it shall be encoded like this:..."? That can still leak
>> information if not handled carefully, but at least it doesn't inhibit
>> optimizations.
>>
>> For a wild handwavy example of an information leak: say you do not
>> include inlined calls in stack frames, and you only inline a call after the
>> 10th invocation. Further assume that you self-host some JS feature. The
>> caller can now learn something about how many times that self-hosted
>> feature has been used. That feature might happen to be Math.something used
>> only for processing non-latin1 characters in a password, or more likely
>> just some feature used only if you are logged into a certain site. (Perhaps
>> Error.stack is already specced to avoid this, by requiring all frames to be
>> included whether inlined or not? Sorry, I don't know anything about it; I'm
>> just posting to ask the question about what specifying stack formats
>> encompasses.)
>>
>
>
> This information leak is not specific to tail-call variance. It is 

Re: Error stack strawman

[Mark S. Miller]

On Wed, Feb 24, 2016 at 11:40 AM, Steve Fink  wrote:

> On 02/19/2016 01:26 AM, Andreas Rossberg wrote:
>
> On 19 February 2016 at 03:13, Gary Guo  wrote:
>
> If we are not going to indicate tail call some way, debugging might be
>> extremely difficult, and the stack result might be making no sense at all.
>>
>
> A tail call is a jump. Just like other jumps, you shouldn't expect their
> history to be visible in the continuation (which is what a stack trace
> represents). I agree that JS programmers might be surprised, and will have
> to relearn what they know. But wrt to debugging the situation is the same
> as for loops: you can't inspect their history either. (And functional
> programmers in fact see loops as just an ugly way to express self tail
> recursion. :) )
>
>
> To be even more pedantic: the stack trace isn't "the" continuation, it is
> one possible continuation. Other continuations are possible if you throw an
> exception. I guess you could say the stack trace plus the code allows you
> to statically derive the full set of possible continuations.
>
> But I agree that it's worthwhile to remember the difference, since what is
> being requested for stacks really *is* a history, not a continuation. For
> example, it is desireable to encode "long stacks" or "async stacks" or
> whatever they're being called these days, where eg for an event handler you
> get the stack trace at the point the handler was installed. That is not a
> continuation, that is history. I would be very wary of mandating that full
> history be preserved, since it's easy for it to prevent optimizations or
> inadvertently leak details of the underlying implementation (tail calls,
> inlining, captured environments).
>
> Does it work to specify something like "if and only if the information is
> available, it shall be encoded like this:..."? That can still leak
> information if not handled carefully, but at least it doesn't inhibit
> optimizations.
>
> For a wild handwavy example of an information leak: say you do not include
> inlined calls in stack frames, and you only inline a call after the 10th
> invocation. Further assume that you self-host some JS feature. The caller
> can now learn something about how many times that self-hosted feature has
> been used. That feature might happen to be Math.something used only for
> processing non-latin1 characters in a password, or more likely just some
> feature used only if you are logged into a certain site. (Perhaps
> Error.stack is already specced to avoid this, by requiring all frames to be
> included whether inlined or not? Sorry, I don't know anything about it; I'm
> just posting to ask the question about what specifying stack formats
> encompasses.)
>


This information leak is not specific to tail-call variance. It is a
problem with the whole error.stack interface <
http://www.combex.com/papers/darpa-review/security-review.html#UniversalScope>.
Like makeWeakRef , that is why
the getStack and getStackString functions won't be generally available to
confined code, but must instead be virtualizable or deniable. Starting with
KeyKOS, capability practitioners refer to this category as "closely held",
as opposed to "ambient". *Everything* in the ES6 standard itself is
ambient, since we postponed spec'ing anything that needs to be closely
held. Now is that time .

Again, as with makeWeakRef, by treating getStack and getStackString as
closely held, it is also less damaging[1] for them to leak implementation
non-determinacy that may carry side channels or covert channels.

[1] It is less damaging when the leakage is limited to intra-realm, since
one realm is not in a position to police another. For getStack and
getStackString, this is yet another reason we need to think hard about
cross-realm stacks. I, for one, have not yet done so.

-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Steve Fink]

On 02/19/2016 01:26 AM, Andreas Rossberg wrote:
On 19 February 2016 at 03:13, Gary Guo > wrote:


If we are not going to indicate tail call some way, debugging
might be extremely difficult, and the stack result might be making
no sense at all.


A tail call is a jump. Just like other jumps, you shouldn't expect 
their history to be visible in the continuation (which is what a stack 
trace represents). I agree that JS programmers might be surprised, and 
will have to relearn what they know. But wrt to debugging the 
situation is the same as for loops: you can't inspect their history 
either. (And functional programmers in fact see loops as just an ugly 
way to express self tail recursion. :) )


To be even more pedantic: the stack trace isn't "the" continuation, it 
is one possible continuation. Other continuations are possible if you 
throw an exception. I guess you could say the stack trace plus the code 
allows you to statically derive the full set of possible continuations.


But I agree that it's worthwhile to remember the difference, since what 
is being requested for stacks really *is* a history, not a continuation. 
For example, it is desireable to encode "long stacks" or "async stacks" 
or whatever they're being called these days, where eg for an event 
handler you get the stack trace at the point the handler was installed. 
That is not a continuation, that is history. I would be very wary of 
mandating that full history be preserved, since it's easy for it to 
prevent optimizations or inadvertently leak details of the underlying 
implementation (tail calls, inlining, captured environments).


Does it work to specify something like "if and only if the information 
is available, it shall be encoded like this:..."? That can still leak 
information if not handled carefully, but at least it doesn't inhibit 
optimizations.


For a wild handwavy example of an information leak: say you do not 
include inlined calls in stack frames, and you only inline a call after 
the 10th invocation. Further assume that you self-host some JS feature. 
The caller can now learn something about how many times that self-hosted 
feature has been used. That feature might happen to be Math.something 
used only for processing non-latin1 characters in a password, or more 
likely just some feature used only if you are logged into a certain 
site. (Perhaps Error.stack is already specced to avoid this, by 
requiring all frames to be included whether inlined or not? Sorry, I 
don't know anything about it; I'm just posting to ask the question about 
what specifying stack formats encompasses.)


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Andreas Rossberg]

On 24 February 2016 at 02:01, John Lenz  wrote:

> To be clear I meant, the VM knows *statically* whether to write code for a
> regular call or a tail call and that it is *possible* to do something
> *clever* by inspecting and rewriting the stack.  Specifically, if you can
> inspect the stack for something that is inserted before performing the
> first tail call it is *possible* possible to distinguish.   This is both
> complicated and potentially costly and very likely not worth the effort.
>

A function can only find out whether it is performing the "first" tail call
if it can find out whether it was tail-called itself. So _every_ tail call
would have to inspect the stack to look for the special tail call frame, in
order to decide whether it should push that special frame itself. So yes,
that would make tail calls prohibitively expensive.

/Andreas


On Fri, Feb 19, 2016 at 1:53 AM, Andreas Rossberg 
> wrote:
>
>>
>>
>> On 19 February 2016 at 10:29, Andreas Rossberg 
>> wrote:
>>
>>> On 19 February 2016 at 06:29, John Lenz  wrote:
>>>
 However, at the CPU level, it seems like you would be better pushing an
 return address for a special function that indicated the start of a
 sequence of tail calls.  That way you trade only some
 complexity/performance for tail calls (an inspection of the last entry of
 the call stack) and some stack frame building complexity (to recognize this
 "special" frame).

>>>
>>> There is no way of knowing, neither statically nor dynamically, that you
>>> are at "the start of a sequence of tail calls". And doing it for every tail
>>> call would of course defeat tail calls.
>>>
>>
>> Or to put that differently: if there was, then the very problem wouldn't
>> exist. ;)
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[John Lenz]

To be clear I meant, the VM knows *statically* whether to write code for a
regular call or a tail call and that it is *possible* to do something
*clever* by inspecting and rewriting the stack.  Specifically, if you can
inspect the stack for something that is inserted before performing the
first tail call it is *possible* possible to distinguish.   This is both
complicated and potentially costly and very likely not worth the effort.








On Fri, Feb 19, 2016 at 1:53 AM, Andreas Rossberg 
wrote:

>
>
> On 19 February 2016 at 10:29, Andreas Rossberg 
> wrote:
>
>> On 19 February 2016 at 06:29, John Lenz  wrote:
>>
>>> However, at the CPU level, it seems like you would be better pushing an
>>> return address for a special function that indicated the start of a
>>> sequence of tail calls.  That way you trade only some
>>> complexity/performance for tail calls (an inspection of the last entry of
>>> the call stack) and some stack frame building complexity (to recognize this
>>> "special" frame).
>>>
>>
>> There is no way of knowing, neither statically nor dynamically, that you
>> are at "the start of a sequence of tail calls". And doing it for every tail
>> call would of course defeat tail calls.
>>
>
> Or to put that differently: if there was, then the very problem wouldn't
> exist. ;)
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Isiah Meadows]

Would it be possible to just define functions with an offset of exactly N
bits before, with tail calls having a separate entry point than regular
calls? Tail calls are already determined statically by spec, so you could
add/subtract N bits to the code you generate for a function call in
optimized code. And the offset could push a boolean to the stack with argc,
etc., saying "this was called via tail call". When this function returns,
tail call or not, this hidden boolean would be popped off.

This flag would be read during stack unwinding, and you could then
add/subtract the offset if it's a tall call to get the real address of the
function, and then do whatever.

As for interpreters, a single boolean flag can still be used. But that
optimization would be a little more difficult.

(Yes, I saw that John Lenz suggested similar, but I'm not suggesting trying
to detect this purely at runtime. That's the point of tail calls. I'm
instead suggesting the entry point be different by a static offset, which
*can* be determined statically.)
On Fri, Feb 19, 2016, 04:54 Andreas Rossberg  wrote:

> On 19 February 2016 at 10:29, Andreas Rossberg 
> wrote:
>
>> On 19 February 2016 at 06:29, John Lenz  wrote:
>>
>>> However, at the CPU level, it seems like you would be better pushing an
>>> return address for a special function that indicated the start of a
>>> sequence of tail calls.  That way you trade only some
>>> complexity/performance for tail calls (an inspection of the last entry of
>>> the call stack) and some stack frame building complexity (to recognize this
>>> "special" frame).
>>>
>>
>> There is no way of knowing, neither statically nor dynamically, that you
>> are at "the start of a sequence of tail calls". And doing it for every tail
>> call would of course defeat tail calls.
>>
>
> Or to put that differently: if there was, then the very problem wouldn't
> exist. ;)
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Andreas Rossberg]

On 19 February 2016 at 10:29, Andreas Rossberg  wrote:

> On 19 February 2016 at 06:29, John Lenz  wrote:
>
>> However, at the CPU level, it seems like you would be better pushing an
>> return address for a special function that indicated the start of a
>> sequence of tail calls.  That way you trade only some
>> complexity/performance for tail calls (an inspection of the last entry of
>> the call stack) and some stack frame building complexity (to recognize this
>> "special" frame).
>>
>
> There is no way of knowing, neither statically nor dynamically, that you
> are at "the start of a sequence of tail calls". And doing it for every tail
> call would of course defeat tail calls.
>

Or to put that differently: if there was, then the very problem wouldn't
exist. ;)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Andreas Rossberg]

On 19 February 2016 at 06:29, John Lenz  wrote:

> However, at the CPU level, it seems like you would be better pushing an
> return address for a special function that indicated the start of a
> sequence of tail calls.  That way you trade only some
> complexity/performance for tail calls (an inspection of the last entry of
> the call stack) and some stack frame building complexity (to recognize this
> "special" frame).
>

There is no way of knowing, neither statically nor dynamically, that you
are at "the start of a sequence of tail calls". And doing it for every tail
call would of course defeat tail calls.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Andreas Rossberg]

On 19 February 2016 at 03:13, Gary Guo  wrote:

> Andreas  wrote:
> > This would be fairly difficult to support by implementations. In V8, for
> example, we currently have no way of reconstructing that information, nor
> would it be easy or cheap to add that. A frame is created by the callee,
> but that does not know how it got called. Funnelling through that
> information would effectively require a hidden extra argument to _every_
> call.
>
> Placing a boolean flag theoretically should not introduce too much
> overhead.
>

Practically, though, as I said, it would require passing an extra argument
with every call, even if its information content is just a bit (or
equivalently, having two entry points to every function, which would be
"fun"). It also requires storing this bit in every stack frame, which, for
V8 at least, would require allocating an additional word in every stack
frame, because there is no other space left for it. So, it would likely be
_substantial_ overhead in calling conventions, in both time and space.



> If we are not going to indicate tail call some way, debugging might be
> extremely difficult, and the stack result might be making no sense at all.
>

A tail call is a jump. Just like other jumps, you shouldn't expect their
history to be visible in the continuation (which is what a stack trace
represents). I agree that JS programmers might be surprised, and will have
to relearn what they know. But wrt to debugging the situation is the same
as for loops: you can't inspect their history either. (And functional
programmers in fact see loops as just an ugly way to express self tail
recursion. :) )

I'd argue that the real problem is that ES6 repurposed existing return
syntax for tail calls. This would probably be much less of an issue if tail
calls were a syntactically explicit feature. I wonder if we can still fix
that...

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[John Lenz]

On Thu, Feb 18, 2016 at 6:13 PM, Gary Guo  wrote:

> Andreas  wrote:
> > This would be fairly difficult to support by implementations. In V8, for
> example, we currently have no way of reconstructing that information, nor
> would it be easy or cheap to add that. A frame is created by the callee,
> but that does not know how it got called. Funnelling through that
> information would effectively require a hidden extra argument to _every_
> call.
>
> Placing a boolean flag theoretically should not introduce too much
> overhead. If we are not going to indicate tail call some way, debugging
> might be extremely difficult, and the stack result might be making no sense
> at all.
>

This smells wrong to me from a performance perspective and seems like a
painful cross cutting concern.  You would basically be trading the gains
from tail-calls improves for complexity and cost everywhere else (an extra
parameter for every call means a shorter stack).  For instance, VM/native
interfaces would always need a proxy to provide or be modified to carry
this bit.If it were implemented as a extra parameter, this means at
least one slot or stack push.

However, at the CPU level, it seems like you would be better pushing an
return address for a special function that indicated the start of a
sequence of tail calls.  That way you trade only some
complexity/performance for tail calls (an inspection of the last entry of
the call stack) and some stack frame building complexity (to recognize this
"special" frame).

It been a long time since I've worked directly with assembly, stack frames,
and calling conventions and don't know how feasible this would be on
modern/unique CPU/GPUs that are likely to have JS VMs.



>
> ---
>
> As for how to distinguish between special code source, such as native, if
> https://github.com/tc39/ecma262/issues/395 is resolved, we can use the
> built-in module name for the "source" field, and hopefully we can reserve
> some special built-in module name for native code, cross realm code, etc,
> and then we can have a unified representation of all frames.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Mark S. Miller]

On Thu, Feb 18, 2016 at 6:13 PM, Gary Guo  wrote:

> Andreas  wrote:
> > This would be fairly difficult to support by implementations. In V8, for
> example, we currently have no way of reconstructing that information, nor
> would it be easy or cheap to add that. A frame is created by the callee,
> but that does not know how it got called. Funnelling through that
> information would effectively require a hidden extra argument to _every_
> call.
>
> Placing a boolean flag theoretically should not introduce too much
> overhead. If we are not going to indicate tail call some way, debugging
> might be extremely difficult, and the stack result might be making no sense
> at all.
>
> ---
>
> As for how to distinguish between special code source, such as native, if
> https://github.com/tc39/ecma262/issues/395 is resolved, we can use the
> built-in module name for the "source" field, and hopefully we can reserve
> some special built-in module name for native code, cross realm code, etc,
> and then we can have a unified representation of all frames.
>

I like that! At least for the native case. I don't yet have coherent
thoughts regarding the cross-realm issues.



>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Error stack strawman

[Gary Guo]

Andreas  wrote:> This would be fairly difficult to support 
by implementations. In V8, for example, we currently have no way of 
reconstructing that information, nor would it be easy or cheap to add that. A 
frame is created by the callee, but that does not know how it got called. 
Funnelling through that information would effectively require a hidden extra 
argument to _every_ call.
Placing a boolean flag theoretically should not introduce too much overhead. If 
we are not going to indicate tail call some way, debugging might be extremely 
difficult, and the stack result might be making no sense at all.
---
As for how to distinguish between special code source, such as native, if 
https://github.com/tc39/ecma262/issues/395 is resolved, we can use the built-in 
module name for the "source" field, and hopefully we can reserve some special 
built-in module name for native code, cross realm code, etc, and then we can 
have a unified representation of all frames.
 ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Andreas Rossberg]

On 18 February 2016 at 02:36, Gary Guo  wrote:

> * isTail will be set when the frame indicates a frame created by tail call
> instead of normal function call. Caller's frame is already removed so we
> need some indication for that to help debugging.
>

This would be fairly difficult to support by implementations. In V8, for
example, we currently have no way of reconstructing that information, nor
would it be easy or cheap to add that. A frame is created by the callee,
but that does not know how it got called. Funnelling through that
information would effectively require a hidden extra argument to _every_
call.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[John Lenz]

Mark Knichel has a lot of information regarding stacks and error handling
in various browsers here:  https://github.com/mknichel/javascript-errors

On Wed, Feb 17, 2016 at 4:19 PM, Gary Guo <nbdd0...@hotmail.com> wrote:

> The strawman looks very old, so I've created a new one.
>
> Repo: https://github.com/nbdd0121/es-error-stack
>
> I've collected many information about current implementation from IE,
> Edge, Chrome and Firefox, but missing Safari's. Many thanks if some one can
> collect these info and create a pull request.
>
> I haven't write anything for API part, as you will see from the "concerns"
> part, there are many edge cases to be considered: cross-realm, native,
> global, eval, new Function, anonymous and tail call. All of these need to
> be resolved before we can trying to design an object representation of
> stack frame.
>
> Personally I suggest "(global code)" for global, "(eval code)"  for eval,
> "(Function code)" for new Function, "(anonymous function)" for anonymous
> function/lambda. For native call, we can simply replace filename & line &
> column by "(native)". For tail call I suggest add "(tail)" some where. I
> also suggest adding "(other realm)" or something alike to indicate realm
> boundary is crossed.
>
> For object representation, I hope something like
> ```
> {
>   name: 'string', // (global code), etc for special case, with parenthesis
>   source: 'url', // (native) for native code, with parenthesis
>   line: 'integer',
>   column: 'integer',
>   isTail: 'boolean'
> }
> ```
> And null entry indicating crossing realm. BTW, shall we add reference to
> function in the object representation?
>
> Gary Guo
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Mark Miller]

On Wed, Feb 17, 2016 at 5:36 PM, Gary Guo <nbdd0...@hotmail.com> wrote:

> * isTail will be set when the frame indicates a frame created by tail call
> instead of normal function call. Caller's frame is already removed so we
> need some indication for that to help debugging.
>

Nice


>
> * For span, I put only one pair of line/column there as it is the common
> implementation, but I agree that a starting position and a ending one is
> useful.
>
> * For source, nested frame could be useful but it is not implemented by
> all implementations, and in fact we need an extra field to distinguish eval
> and new Function.
>

For eval vs Function (vs GeneratorFunction, vs AsyncFunction, etc), doesn't
the name inside the nested frame already deal with that?


>
> * By reference to function, I mean that shall we be able to retrieve the
> function object from the frame?
>

No, absolutely not. The stack rep should provide only info, not access.


>
> * I wonder if putting special cases in (), such as (native) will cause any
> problem. No one will have a file called "(native)" in reality, isn't it?
>

If you do this, they will ;)


>
> Gary Guo
>
> --
> Date: Wed, 17 Feb 2016 17:04:39 -0800
> Subject: Re: Error stack strawman
> From: erig...@google.com
> To: nbdd0...@hotmail.com
> CC: es-discuss@mozilla.org
>
>
>
>
> On Wed, Feb 17, 2016 at 4:19 PM, Gary Guo <nbdd0...@hotmail.com> wrote:
>
> The strawman looks very old, so I've created a new one.
>
> Repo: https://github.com/nbdd0121/es-error-stack
>
> I've collected many information about current implementation from IE,
> Edge, Chrome and Firefox, but missing Safari's. Many thanks if some one can
> collect these info and create a pull request.
>
> I haven't write anything for API part, as you will see from the "concerns"
> part, there are many edge cases to be considered: cross-realm, native,
> global, eval, new Function, anonymous and tail call. All of these need to
> be resolved before we can trying to design an object representation of
> stack frame.
>
> Personally I suggest "(global code)" for global, "(eval code)"  for eval,
> "(Function code)" for new Function, "(anonymous function)" for anonymous
> function/lambda. For native call, we can simply replace filename & line &
> column by "(native)". For tail call I suggest add "(tail)" some where. I
> also suggest adding "(other realm)" or something alike to indicate realm
> boundary is crossed.
>
> For object representation, I hope something like
> ```
> {
>   name: 'string', // (global code), etc for special case, with parenthesis
>   source: 'url', // (native) for native code, with parenthesis
>   line: 'integer',
>   column: 'integer',
>   isTail: 'boolean'
> }
> ```
>
>
> Unless the object representation is primary, we will need to agree on
> comprehensive escaping rules, and corresponding parsing rules, so that
> these stack strings can be unambiguously scraped even when file names and
> function names contain parens, slashes, angle brackets, at-signs, spaces,
> etc. Therefore, we should focus on the object representation first.
>
> Your object representation above looks like a good start. It is similar to
> the extended Causeway stack format I mentioned earlier
>
> stacktrace ::= {calls: [frame*]};
> frame ::= {name: functionName,
>source: source,
>span: [[startLine,startCol?],[endLine,endCol?]?]};
> functionName ::= STRING;
> startLine, startCol, endLine, endCol ::= INTEGER
> source ::= STRING | frame;
>
> with the following differences:
>
> * You added an isTail. This is probably a good thing. I'd like to
> understand better what you have in mind.
>
> * Rather than have a single "span" property with a nested array of numbers
> as value, you define separate line and column property names. As long as we
> represent all that we need unambiguously, I'm indifferent to minor surface
> syntax differences.
>
> * Causeway's format has room for both start(line,col) and end(line,col).
> The format must include room for this, and I would hope any future standard
> would mandate that they be included. Such span information makes a huge
> usability improvement in reporting diagnostics.
>
> * The extended Causeway "source" field could be either a string as with
> your's, or a nested frame. This is necessary to preserve the information
> currently provided on both FF and Chrome of the nested positions in a
> single frame, when a call happens at position X in an eval string that was
> evaled by an eval cal

RE: Error stack strawman

[Gary Guo]

* isTail will be set when the frame indicates a frame created by tail call 
instead of normal function call. Caller's frame is already removed so we need 
some indication for that to help debugging.
* For span, I put only one pair of line/column there as it is the common 
implementation, but I agree that a starting position and a ending one is useful.
* For source, nested frame could be useful but it is not implemented by all 
implementations, and in fact we need an extra field to distinguish eval and new 
Function.
* By reference to function, I mean that shall we be able to retrieve the 
function object from the frame?
* I wonder if putting special cases in (), such as (native) will cause any 
problem. No one will have a file called "(native)" in reality, isn't it?
Gary Guo

Date: Wed, 17 Feb 2016 17:04:39 -0800
Subject: Re: Error stack strawman
From: erig...@google.com
To: nbdd0...@hotmail.com
CC: es-discuss@mozilla.org



On Wed, Feb 17, 2016 at 4:19 PM, Gary Guo <nbdd0...@hotmail.com> wrote:






The strawman looks very old, so I've created a new one.
Repo: https://github.com/nbdd0121/es-error-stack
I've collected many information about current implementation from IE, Edge, 
Chrome and Firefox, but missing Safari's. Many thanks if some one can collect 
these info and create a pull request.
I haven't write anything for API part, as you will see from the "concerns" 
part, there are many edge cases to be considered: cross-realm, native, global, 
eval, new Function, anonymous and tail call. All of these need to be resolved 
before we can trying to design an object representation of stack frame.
Personally I suggest "(global code)" for global, "(eval code)"  for eval, 
"(Function code)" for new Function, "(anonymous function)" for anonymous 
function/lambda. For native call, we can simply replace filename & line & 
column by "(native)". For tail call I suggest add "(tail)" some where. I also 
suggest adding "(other realm)" or something alike to indicate realm boundary is 
crossed.
For object representation, I hope something like ```{  name: 'string', // 
(global code), etc for special case, with parenthesis  source: 'url', // 
(native) for native code, with parenthesis  line: 'integer',  column: 
'integer',  isTail: 'boolean'}```
Unless the object representation is primary, we will need to agree on 
comprehensive escaping rules, and corresponding parsing rules, so that these 
stack strings can be unambiguously scraped even when file names and function 
names contain parens, slashes, angle brackets, at-signs, spaces, etc. 
Therefore, we should focus on the object representation first.
Your object representation above looks like a good start. It is similar to the 
extended Causeway stack format I mentioned earlier 
stacktrace ::= {calls: [frame*]};frame ::= {name: functionName, 
  source: source,   span: 
[[startLine,startCol?],[endLine,endCol?]?]};functionName ::= STRING;
startLine, startCol, endLine, endCol ::= INTEGERsource ::= STRING | frame;

with the following differences:
* You added an isTail. This is probably a good thing. I'd like to understand 
better what you have in mind.
* Rather than have a single "span" property with a nested array of numbers as 
value, you define separate line and column property names. As long as we 
represent all that we need unambiguously, I'm indifferent to minor surface 
syntax differences.
* Causeway's format has room for both start(line,col) and end(line,col). The 
format must include room for this, and I would hope any future standard would 
mandate that they be included. Such span information makes a huge usability 
improvement in reporting diagnostics.
* The extended Causeway "source" field could be either a string as with your's, 
or a nested frame. This is necessary to preserve the information currently 
provided on both FF and Chrome of the nested positions in a single frame, when 
a call happens at position X in an eval string that was evaled by an eval call 
at position Y. (That is what the "extended" means. Causeway originally only has 
strings as the value of their "source" property.)
The proposed[1] API is:
System.getStack(err) -> 
stack-representationReflect.stackString(stack-representation) -> 
stack-stringSystem.getStackString(err) -> stack-string
where getStackString is just the obvious composition of getStack and 
stackString.
 And null entry indicating crossing realm. BTW, shall we add reference to 
function in the object representation?
What do you mean by "reference to" above?

[1] Hopefully https://github.com/tc39/ecma262/issues/395 will resolve in time 
that none of these need to be rooted in globals.
 
Gary Guo
  

___

es-discuss mailing list

es-discuss@moz

Re: Error stack strawman

[Mark S. Miller]

On Wed, Feb 17, 2016 at 4:19 PM, Gary Guo <nbdd0...@hotmail.com> wrote:

> The strawman looks very old, so I've created a new one.
>
> Repo: https://github.com/nbdd0121/es-error-stack
>
> I've collected many information about current implementation from IE,
> Edge, Chrome and Firefox, but missing Safari's. Many thanks if some one can
> collect these info and create a pull request.
>
> I haven't write anything for API part, as you will see from the "concerns"
> part, there are many edge cases to be considered: cross-realm, native,
> global, eval, new Function, anonymous and tail call. All of these need to
> be resolved before we can trying to design an object representation of
> stack frame.
>
> Personally I suggest "(global code)" for global, "(eval code)"  for eval,
> "(Function code)" for new Function, "(anonymous function)" for anonymous
> function/lambda. For native call, we can simply replace filename & line &
> column by "(native)". For tail call I suggest add "(tail)" some where. I
> also suggest adding "(other realm)" or something alike to indicate realm
> boundary is crossed.
>
> For object representation, I hope something like
> ```
> {
>   name: 'string', // (global code), etc for special case, with parenthesis
>   source: 'url', // (native) for native code, with parenthesis
>   line: 'integer',
>   column: 'integer',
>   isTail: 'boolean'
> }
> ```
>

Unless the object representation is primary, we will need to agree on
comprehensive escaping rules, and corresponding parsing rules, so that
these stack strings can be unambiguously scraped even when file names and
function names contain parens, slashes, angle brackets, at-signs, spaces,
etc. Therefore, we should focus on the object representation first.

Your object representation above looks like a good start. It is similar to
the extended Causeway stack format I mentioned earlier

stacktrace ::= {calls: [frame*]};
frame ::= {name: functionName,
   source: source,
   span: [[startLine,startCol?],[endLine,endCol?]?]};
functionName ::= STRING;
startLine, startCol, endLine, endCol ::= INTEGER
source ::= STRING | frame;

with the following differences:

* You added an isTail. This is probably a good thing. I'd like to
understand better what you have in mind.

* Rather than have a single "span" property with a nested array of numbers
as value, you define separate line and column property names. As long as we
represent all that we need unambiguously, I'm indifferent to minor surface
syntax differences.

* Causeway's format has room for both start(line,col) and end(line,col).
The format must include room for this, and I would hope any future standard
would mandate that they be included. Such span information makes a huge
usability improvement in reporting diagnostics.

* The extended Causeway "source" field could be either a string as with
your's, or a nested frame. This is necessary to preserve the information
currently provided on both FF and Chrome of the nested positions in a
single frame, when a call happens at position X in an eval string that was
evaled by an eval call at position Y. (That is what the "extended" means.
Causeway originally only has strings as the value of their "source"
property.)

The proposed[1] API is:

System.getStack(err) -> stack-representation
Reflect.stackString(stack-representation) -> stack-string
System.getStackString(err) -> stack-string

where getStackString is just the obvious composition of getStack and
stackString.



> And null entry indicating crossing realm. BTW, shall we add reference to
> function in the object representation?
>

What do you mean by "reference to" above?


[1] Hopefully https://github.com/tc39/ecma262/issues/395 will resolve in
time that none of these need to be rooted in globals.



>
> Gary Guo
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Error stack strawman

[Gary Guo]

The strawman looks very old, so I've created a new one.
Repo: https://github.com/nbdd0121/es-error-stack
I've collected many information about current implementation from IE, Edge, 
Chrome and Firefox, but missing Safari's. Many thanks if some one can collect 
these info and create a pull request.
I haven't write anything for API part, as you will see from the "concerns" 
part, there are many edge cases to be considered: cross-realm, native, global, 
eval, new Function, anonymous and tail call. All of these need to be resolved 
before we can trying to design an object representation of stack frame.
Personally I suggest "(global code)" for global, "(eval code)"  for eval, 
"(Function code)" for new Function, "(anonymous function)" for anonymous 
function/lambda. For native call, we can simply replace filename & line & 
column by "(native)". For tail call I suggest add "(tail)" some where. I also 
suggest adding "(other realm)" or something alike to indicate realm boundary is 
crossed.
For object representation, I hope something like ```{  name: 'string', // 
(global code), etc for special case, with parenthesis  source: 'url', // 
(native) for native code, with parenthesis  line: 'integer',  column: 
'integer',  isTail: 'boolean'}```And null entry indicating crossing realm. BTW, 
shall we add reference to function in the object representation?
Gary Guo
  ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Terry Stanley]

[+es-discuss] resending with es-discuss included.


On Tue, Feb 9, 2016 at 9:48 PM, Terry Stanley  wrote:

> Hi Boris,
>
> I've recently made changes to Causeway that I think you'll be interested
> in. The (revived) Stack Explorer view will give you a hands-on sense of our
> support of async stacks.
>
> Stefan, Mark, and John, I'm cc'ing you because of your interest in these
> matters.
>
> The web page shows our "go-to" example program -- the purchase order
> example. The program is run in the browser, trace logs are generated, then
> the Causeway viewer shows 1) happened-before grid view 2) message-order
> view and 3) stack explorer. The views support synchronized selection and
> focus, so together, they help explain asynchronous message flow.
>
> When you visit
>
> https://rawgit.com/cocoonfx/causeway/master/src/js/com/teleometry/causalityGrid.html
> you will see 3 views of the Firefox trace. Click on the bottom-right
> colored square to get going. The upper-left view is the Stack Explorer,
> showing the deep stack that led to the selected event.
>
> Each color is associated with a different vat. The blue is for the main
> window, green and brown are each a worker. The important thing here is that
> all 3 views show causality as it crosses worker boundaries.
>
> The purchase order example is explained in the Causeway paper
> http://www.hpl.hp.com/techreports/2009/HPL-2009-78.html
>
> The source code is at:
>
> https://github.com/cocoonfx/causeway/tree/master/src/js/com/teleometry/causeway/purchase_example/workers
>
> I incorporated MarkM's stack-scraping code (from SES) into Causeway,
> enabling it to collect stack traces in all browsers.
>
> https://github.com/cocoonfx/causeway/blob/master/src/js/com/teleometry/causeway/purchase_example/workers/debug.js
>
>
>
>
> On Fri, Jan 22, 2016 at 2:52 PM, Boris Zbarsky  wrote:
>
>> On 1/22/16 4:51 PM, Terry Stanley wrote:
>>
>>> Breaking on console.log:
>>>FF debugger showed single turn call stack
>>>Chrome debugger with Async selected showed deep stack
>>> Console output:
>>>FF showed deep stack (as expected)
>>>Chrome showed single turn
>>>
>>
>> Seems like people are incrementally introducing this stuff or just have
>> bugs.  :(
>>
>> You are correct. The extended stack trace format in MarkM's message is
>>> not enough to represent async stacks.
>>>
>>
>> OK, it's not just me.  All I'm saying is we should go ahead and use a
>> format that _can_ represent them.
>>
>> The full Causeway format is more
>>> than what's needed for the async stacks you are asking about.
>>>
>>
>> Excellent.  That reduces the problem to using a larger subset of the
>> Causeway format, right?
>>
>> The deep stack you see here follows asynchronous causality as it flows
>>> across worker boundaries.
>>
>>
> Yes, that is correct. The current example does not use promises, and so
> uses essentially what is shown at
> http://wiki.erights.org/wiki/Causeway_Platform_Developer
> To provide quality causality tracing for promise-based code, Causeway uses
> the log record types shown at
> http://wiki.erights.org/wiki/Causeway_Platform_Developer:_Promises
>
>
>
>> That's pretty nifty.  Being able to represent that too would be nice.
>>
>> It would be great to have browser support for such stitching together of
>>> intra-vat (page/worker) and cross-worker causality. Do the Causeway
>>> object formats
>>>  for
>>> representing these look like an interesting start?
>>>
>>
>> I haven't had a chance to study them in detail, but at first glance yes.
>>
>> -Boris
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Boris Zbarsky]

On 2/10/16 4:52 AM, Jonathan Kingston wrote:

@Boris does the main difficulties hinge on document.domain?


Main difficulties with what?

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Boris Zbarsky]

On 2/10/16 9:47 PM, Jonathan Kingston wrote:

Could the trace output just finish early at these origin boundaries


The problem is that some browsers don't have origin boundaries at all in 
places where others do.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Jonathan Kingston]

Just want to keep this going as I think mostly people agree it is worthy as
an addition just the details are difficult etc.

@Boris does the main difficulties hinge on document.domain? There are
discussions again in WebAppSec to deprecate that so perhaps the trace could
also not work if document.domain has been changed.

On Tue, Jan 26, 2016 at 2:20 AM Gary Guo  wrote:

> One thing needs to be considered as well. What should be displayed for
> tail calls?
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Jonathan Kingston]

Yeah interop issues of the output. (Sorry I'm not being clear) It seems the
interop has been the main reason this has stalled as a proposal all these
years.

Could the trace output just finish early at these origin boundaries perhaps
rather than try and implement cross browser? With the right API this could
be added in later if there was agreement.

The discussion at the moment just hinges around dropping it for new API
features rather than break Facebook etc.
https://github.com/w3c/webappsec-secure-contexts/issues/10

On Thu, Feb 11, 2016 at 1:56 AM Boris Zbarsky  wrote:

> On 2/10/16 7:12 PM, Jonathan Kingston wrote:
> > Is implementing stack traces cross browser mostly difficult because of
> > the use of document.domain or are there other issues blocking?
>
> Ah, you mean in terms of interop?
>
> I expect document.domain and built-ins to be the main thing that
> browsers will end up disagreeing if they just implement this
> willy-nilly; everything else is reasonably straightforward.
>
> Deprecating document.domain is a noble goal, but given that sites that
> many people use (e.g. Facebook) make use of it, it's a pretty long-term
> goal at best...
>
> -Boris
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Jonathan Kingston]

Is implementing stack traces cross browser mostly difficult because of the
use of document.domain or are there other issues blocking?

On Wed, Feb 10, 2016 at 3:03 PM Boris Zbarsky  wrote:

> On 2/10/16 4:52 AM, Jonathan Kingston wrote:
> > @Boris does the main difficulties hinge on document.domain?
>
> Main difficulties with what?
>
> -Boris
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Boris Zbarsky]

On 2/10/16 7:12 PM, Jonathan Kingston wrote:

Is implementing stack traces cross browser mostly difficult because of
the use of document.domain or are there other issues blocking?


Ah, you mean in terms of interop?

I expect document.domain and built-ins to be the main thing that 
browsers will end up disagreeing if they just implement this 
willy-nilly; everything else is reasonably straightforward.


Deprecating document.domain is a noble goal, but given that sites that 
many people use (e.g. Facebook) make use of it, it's a pretty long-term 
goal at best...


-Boris


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Error stack strawman

[Gary Guo]

I believe a lot of additional work needs to be done for this proposal to make 
it works across realm. 
Consider the invocation chain:alpha, alpha0 (in realm A)beta, beta0 (in realm 
B)alpha -> alpha0 -> beta -> beta0 -> alpha ->alpha0 -> beta -> beta0 -> throws
Here comes the question. What should be included in the stack and what 
shouldn't?Same thing applies when calling native function. Such thing is 
severely lacking in current proposal.
From: jonat...@jooped.co.uk
Date: Tue, 12 Jan 2016 03:10:12 +0000
Subject: Error stack strawman
To: es-discuss@mozilla.org

Hey all,
Does anyone know if there is an active interest in revisiting the Error.stack 
strawman proposal?
http://wiki.ecmascript.org/doku.php?id=strawman:error_stack

I ask because CSP wanted an algorithm for getting the non standard properties 
defined in Error objects: https://w3c.github.io/webappsec-csp/#issue-f447ede5

A simpler start may be possible in standardising just: lineNumber, columnNumber 
and fileName

Kind regardsJonathan

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
  ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Boris Zbarsky]

On 1/25/16 1:55 PM, Gary Guo wrote:

I believe a lot of additional work needs to be done for this proposal to
make it works across realm.

Consider the invocation chain:
alpha, alpha0 (in realm A)
beta, beta0 (in realm B)
alpha -> alpha0 -> beta -> beta0 -> alpha ->alpha0 -> beta -> beta0 ->
throws

Here comes the question. What should be included in the stack and what
shouldn't?


What browsers will do is basically include everything, with some caveats.

The main caveat I'm aware of is that when the stack crosses between 
realms which have different effective script origins Gecko will sanitize 
the script view of the stack to only include the bits that the script 
asking for the stack is allowed to know about.  We do record the entire 
stack, and can show the entire thing in devtools if we want to.


In practice, such stacks are quite hard to produce on the web; they 
require changing document.domain partway through the script execution.



Same thing applies when calling native function.


Yeah, this needs some thought.  Browsers aren't even terribly consistent 
with each other or with themselves here.  A imple example:


  
  var div = document.createElement("div");
  div.onclick = function f() {
   console.log(new Error().stack);
  }
  div.dispatchEvent(new Event("click"));
  
  
  function g() {
console.log(new Error().stack);
  }
  [0].map(g);
  

this shows the following in Firefox:

  f@filename:4:13
  @filename:6:1

and

  g@filename:10:17
  @filename:12:3

Whereas in Chrome it shows:

 at HTMLDivElement.f (filename1:4)
 at filename1:6

and

 at g (filename2:10:17)
 at Array.map (native)
 at filename2:12:7

where filenam1 and filename2 are actually different: the latter is an 
absolute URI but the former is just the filename part of the URI...


Safari does:

  f@filename:4:22
  dispatchEvent@[native code]
  global code@filename:6:18

and

  g@filename:10:26
  map@[native code]
  global code@filename:12:10

which is what I was sort of hoping to see, possibly with better names 
for the built-ins (e.g. "Array.prototype.map" and 
"Node.prototype.dispatchEvent" or something).


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Error stack strawman

[Gary Guo]

One thing needs to be considered as well. What should be displayed for tail 
calls?___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Boris Zbarsky]

On 1/22/16 4:51 PM, Terry Stanley wrote:

Breaking on console.log:
   FF debugger showed single turn call stack
   Chrome debugger with Async selected showed deep stack
Console output:
   FF showed deep stack (as expected)
   Chrome showed single turn


Seems like people are incrementally introducing this stuff or just have 
bugs.  :(



You are correct. The extended stack trace format in MarkM's message is
not enough to represent async stacks.


OK, it's not just me.  All I'm saying is we should go ahead and use a 
format that _can_ represent them.



The full Causeway format is more
than what's needed for the async stacks you are asking about.


Excellent.  That reduces the problem to using a larger subset of the 
Causeway format, right?



The deep stack you see here follows asynchronous causality as it flows
across worker boundaries.


That's pretty nifty.  Being able to represent that too would be nice.


It would be great to have browser support for such stitching together of
intra-vat (page/worker) and cross-worker causality. Do the Causeway
object formats
 for
representing these look like an interesting start?


I haven't had a chance to study them in detail, but at first glance yes.

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Boris Zbarsky]

On 1/20/16 10:10 AM, Mark S. Miller wrote:

I think the useful thing to do is to standardize the extended
Causeway stack trace format:


This format doesn't have an obvious way to represent "async stacks" [1], 
short of hacks with the "functionName" or the "source", right?


Gecko right now represents these precisely by hacking the function name, 
but that's in the context of backwards compat with existing 
stack-processing tools, and a string-only stack representation.  It 
seems to me that moving to an object format should allow us to come up 
with a cleaner way to do this.


-Boris

[1] To see what I mean, try running this in a Firefox nightly:

  
  
  function g() {
    console.log(new Error().stack);
  }
  function f() {
setTimeout(g, 0);
  }
  f();
  

the output you will get is:

  g@filename:4:17
  setTimeout handler*f@filename:7:5
  @filename:9:3

As in, the stack indicates the sequence of async steps that got you to 
the current source location.


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Mark S. Miller]

On Tue, Jan 19, 2016 at 6:35 PM, Jonathan Kingston <jonat...@jooped.co.uk>
wrote:

> Hi Mark,
>
> Sorry for the delay, thank you for that response it was very useful.
>
> Do you think it would make sense to open an API for Error stack that would
> be purely based upon user agent implementation? I'm not familiar with the
> internals of the traces but I have seen comments mentioning performance
> issues of complete parity across browsers due to their implementation
> differences.
>
> It would however still be useful to standardise: lineNumber, columnNumber
> and fileName.
>
> Perhaps that would be a simpler first step?
>


I think I was too discouraging in my earlier email. I actually meant to be
encouraging, though as always including weaknesses, cautions, requirements,
and caveats. I did not mean to scare anyone off. The downside of starting
with too small a part of the problem in isolation is that we are likely to
paint ourselves into a corner that we cannot fix later. I think the useful
thing to do is to standardize the extended Causeway stack trace format:


stacktrace ::= {calls: [frame*]};
frame ::= {name: functionName,
   source: source,
   span: [[startLine, startCol?], [endLine, endCol?]?]};
functionName ::= STRING;
startLine, startCol, endLine, endCol ::= INTEGER
source ::= STRING | frame;


that I showed in the previous message, as well as the APIs derived from <
https://github.com/google/caja/blob/master/src/com/google/caja/ses/debug.js
>:


System.getStack(error) -> extended-causeway-stack | undefined

Reflect.stackString(extended-causeway-stack) -> stacktrace-string

System.getStackString = error =>
Reflect.stackString(System.getStack(error));


This places the privilege-bearing operations on System, as do other
proposals such as

System.global
System.defaultLoader
System.WeakRef

The only operation above that's fundamental is System.getStack, which,
given an error object encapsulating stack trace info, returns that stack
trace info in extended Causeway stacktrace format. debug.js shows how to
polyfill a decent approximation of this by scraping this info from the
divergent stack traces provided by today's major platforms.

Reflect.stackString renders an extended Causeway stack into a multiline
string, one per stackframe. It is fully non-privileged and polyfillable,
but I propose that the std provide it, in order to harmonize the current
crazy divergence of these formats between platforms. The one provided by
debug.js uses a vaguely v8-like concrete syntax, but that is merely a
starting point of discussion. Anything we can all agree on, that reliably
represents all the information from the extended Causeway stacktrace info,
would be great. We put stackString on Reflect because by itself it provides
no privilege.

System.getStackString is a mere convenience, composing together stackString
with getStack. I expect that most callers will just call this and ignore
the two lower level ones.


The hard part will be the escaping conventions needed in stackString, as
this goes beyond any precedent set by current platforms. The scraping that
the polyfill in debug.js does is grossly unreliable because it relies on
characters such as "(" and "@" to recognize what part of the existing
stackframe strings are filenames and function-or-method names. However,
these characters can be present in filenames, function names, and method
names, in which case this scraping will fail. Neither the current scraping
nor rendering code in debug.js does anything yet about this need to escape
significant characters.

Fortunately, once a reliable getStack is provided directly (instead of a
polyfill scraping non-escaped strings), consumers of the extended Causeway
format it returns will have reliable access to this structured data,
without any more need to do their own scraping.


The other hard but necessary part is that any such standard should be
coordinated -- ideally co-proposed -- with a proposed standard sourcemap <
https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit?hl=en_US=1=1>,
which also needs to codify the meaning of at least filename and start/end
line/col.

A transpiler translating esN+1 to esN, producing an esN to esN+1 sourcemap,
should also provide to the esN+1 code a virtualized System.getStack and
System.getStackString that maps back through that sourcemap, so that the
esN+1 code sees stack trace info in terms of positions in its own esN+1
sources.



What all of this needs is someone who will take the lead writing a
proposal. It is important, but I do not have the time. If someone does
volunteer to take the lead, I will happily help, advise, ensure that all
requirements are met, and to champion this proposal on the committee.
Volunteers? Jonathan?




> Thanks
> Jonathan
>
> On Tue, Jan 12, 2016 at 6:32 A

Re: Error stack strawman

[Jonathan Kingston]

Hi Mark,

Sorry for the delay, thank you for that response it was very useful.

Do you think it would make sense to open an API for Error stack that would
be purely based upon user agent implementation? I'm not familiar with the
internals of the traces but I have seen comments mentioning performance
issues of complete parity across browsers due to their implementation
differences.

It would however still be useful to standardise: lineNumber, columnNumber
and fileName.

Perhaps that would be a simpler first step?

Thanks
Jonathan

On Tue, Jan 12, 2016 at 6:32 AM Mark S. Miller <erig...@google.com> wrote:

> On Mon, Jan 11, 2016 at 10:05 PM, Mark S. Miller <erig...@google.com>
> wrote:
>
>> I am very interested. See the extended Causeway stack format in
>> https://github.com/google/caja/blob/master/src/com/google/caja/ses/debug.js
>>
>
> From that page, the JSON Schema-ish in an ad-hoc notation:
>
>
> stacktrace ::= {calls: [frame*]};
> frame ::= {name: functionName,
>source: source,
>span: [[startLine, startCol?], [endLine, endCol?]?]};
> functionName ::= STRING;
> startLine, startCol, endLine, endCol ::= INTEGER
> source ::= STRING | frame;
>
>
>
>
> and the logic for scraping this information from the various stacktraces
>> available on today's major platforms.
>>
>> The "extended" is about the multiple source position layers present when
>> an "eval" in one place evals a string that, at some position in the string,
>> does the call. Both FF and Chrome provide these nested positions, but
>> differently.
>>
>
>
> The nesting is represented as the recursion through "frame" in the above
> grammar.
>
>
>
>>
>> See the attachments for the information successfully scraped when
>> visiting <https://rawgit.com/tvcutsem/es-lab/master/src/ses/contract.html>
>> on each of the platforms, converted to Causeway extended stack trace
>> format, and then re-rendered in a common textual format. As you see, even
>> with all the work at canonicalizing this information, it still differs
>> substantially between platforms.
>>
>>
>>
>>
>> On Mon, Jan 11, 2016 at 7:10 PM, Jonathan Kingston <jonat...@jooped.co.uk
>> > wrote:
>>
>>> Hey all,
>>>
>>> Does anyone know if there is an active interest in revisiting the
>>> Error.stack strawman proposal?
>>>
>>> http://wiki.ecmascript.org/doku.php?id=strawman:error_stack
>>>
>>> I ask because CSP wanted an algorithm for getting the non standard
>>> properties defined in Error objects:
>>> https://w3c.github.io/webappsec-csp/#issue-f447ede5
>>>
>>> A simpler start may be possible in standardising just: lineNumber,
>>> columnNumber and fileName
>>>
>>> Kind regards
>>> Jonathan
>>>
>>
>
>
> --
> Cheers,
> --MarkM
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Mark S. Miller]

On Mon, Jan 11, 2016 at 10:05 PM, Mark S. Miller  wrote:

> I am very interested. See the extended Causeway stack format in
> https://github.com/google/caja/blob/master/src/com/google/caja/ses/debug.js
>

>From that page, the JSON Schema-ish in an ad-hoc notation:


stacktrace ::= {calls: [frame*]};
frame ::= {name: functionName,
   source: source,
   span: [[startLine, startCol?], [endLine, endCol?]?]};
functionName ::= STRING;
startLine, startCol, endLine, endCol ::= INTEGER
source ::= STRING | frame;




and the logic for scraping this information from the various stacktraces
> available on today's major platforms.
>
> The "extended" is about the multiple source position layers present when
> an "eval" in one place evals a string that, at some position in the string,
> does the call. Both FF and Chrome provide these nested positions, but
> differently.
>


The nesting is represented as the recursion through "frame" in the above
grammar.



>
> See the attachments for the information successfully scraped when visiting
>  on each
> of the platforms, converted to Causeway extended stack trace format, and
> then re-rendered in a common textual format. As you see, even with all the
> work at canonicalizing this information, it still differs substantially
> between platforms.
>
>
>
>
> On Mon, Jan 11, 2016 at 7:10 PM, Jonathan Kingston 
> wrote:
>
>> Hey all,
>>
>> Does anyone know if there is an active interest in revisiting the
>> Error.stack strawman proposal?
>>
>> http://wiki.ecmascript.org/doku.php?id=strawman:error_stack
>>
>> I ask because CSP wanted an algorithm for getting the non standard
>> properties defined in Error objects:
>> https://w3c.github.io/webappsec-csp/#issue-f447ede5
>>
>> A simpler start may be possible in standardising just: lineNumber,
>> columnNumber and fileName
>>
>> Kind regards
>> Jonathan
>>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Error stack strawman

[Jonathan Kingston]

Hey all,

Does anyone know if there is an active interest in revisiting the
Error.stack strawman proposal?

http://wiki.ecmascript.org/doku.php?id=strawman:error_stack

I ask because CSP wanted an algorithm for getting the non standard
properties defined in Error objects:
https://w3c.github.io/webappsec-csp/#issue-f447ede5

A simpler start may be possible in standardising just: lineNumber,
columnNumber and fileName

Kind regards
Jonathan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Mark S. Miller]

On Tue, Jun 12, 2012 at 9:17 AM, Brendan Eich bren...@mozilla.org wrote:
 Mark S. Miller wrote:

 On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eichbren...@mozilla.org  wrote:

 Also, as you pointed out, even error.stack leaks information. Where do
 you
 draw the line?


 Conservatively. I suggest that there be no error.stack, but rather
 getStack(error), in order to avoid this information leak.


 With some kind of

  import getStack from @reflect;

 or similar, and SES uses a custom loader to censor @reflect?

Yes, that's the kind of thing I have in mind. Perhaps an @privileged?


 This is a matter of preference, not necessity, if we're talking about the
 language as it is. We won't be making use strict the default. We are
 trying to avoid more modes (1JS). We're not talking about SES. So I don't
 see how it can be argued logically that a non-strict-only
 arguments-disclosing stack-tracing API is either never helpful nor always
 helpful. YMMV.

I'm not yet arguing that or the opposite, rather, I'm confused about
what non-strict-only means in this context. Actual stacks consist of
a mixture of strict and non-strict activations. How would the proposed
API deal with that?


 I see -- thanks. We should try to detail the privileged APIs and their
 module(s) a bit more. I used @reflect above but I didn't mean to equate it
 to Tom's Reflect.* used in conjunction with direct proxies. And not all
 reflection facilities are privileged -- more the reverse for the direct
 proxy stuff, right?

yup. JS is an amazingly reflective language. We've taken care in both
the ES5 and ES6 efforts that all reflective operations uphold the ocap
security of strict functions -- so far without needing a special
@privileged module. getStack and makeWeakRef are the first reflective
operations that do require some such privilege separation.

Given an @privileged module and a desire to inspect the arguments of
non-strict activations, we should consider whether @privileged should
also grant the ability to inspect the arguments of strict activations.

Is @privileged per global context (frame)? If so, does it only provide
privileges over objects from that same global context? Or is it more
like browser chrome js vs page js, where special chrome privileges
apply to all page js objects it encounters? Might we eventually
standardize a module that provides all the privileges needed to
implement a portable debugger? Is it appropriate for the language to
define multiple kinds of privilege-granting modules, or should the
language delegate this to the host?

-- 
    Cheers,
    --MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Mark S. Miller]

On Tue, Jun 12, 2012 at 10:14 AM, Charles Kendrick
char...@isomorphic.com wrote:
 On Mon, Jun 11, 2012 at 5:55 PM, Mark S. Miller erig...@google.com wrote:
 On Tue, Jun 12, 2012 at 7:59 AM, Charles Kendrick
 char...@isomorphic.com wrote:
 I'm reading this as saying that stack traces in general should not be
 available unless the code is privileged in some way.  This can't be
 what you mean, so could you clarify?

 That is exactly what I mean.

 The only way I can see this working is if there is a way for a given
 piece of code to trap an error and ask some kind of (elevated
 privilege) logging system to provide diagnostic information that a
 (privileged) end user can see.

I'm not sure what you mean by trap to an error, but the rest of your
description seems close to how SES's console.log, console.warn, etc
work. They are endowed with access to the privileged getStack function
and use it to display stack traces on the console's output. See
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/logger.js#28
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/logger.js#157
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/useHTMLLogger.js#116

We assume that unprivileged code generally has no way to read the
console's output.


  It also seems like, in addition to
 this, you should be able to get to stack information programmatically
 so long as you stay within your module or modules that have the same
 privilege.

If we're talking about code with some privilege to see some stacks,
why not reify such privilege in a getStack function importable from
some @privileged module? If you don't reify this distinction, then
you're suggesting above that an access be dependent on the module from
which the access is directly made. What if the access is made
indirectly through some intermediary? Does it then fail, even though
all other accesses can be delegated to the same intermediary? If the
access is simply a property access,

function intermediary(base, name) { return base[name]; }

defined in some other module.


 This doesn't sound like something that could be reasonably
 standardized into ECMAScript in the near future, and, without all
 those pieces in place, it doesn't seem like ECMAScript should just
 disallow the ability to get stack traces.

In this thread, we've already considered APIs other than .stack.
Given anything else, why is getStack(err) is any worse than
introducing a novel property name?

Regarding near future, any such proposal -- whether .stack,
getStack, or whatever -- has already missed the boat for ES6. getStack
certainly could be considered in an ES7 timeframe.


 Brendan brought up SES - I know little about it, but for its sake I
 hope this critical use case is taken into account.

Yes. The code I link to above dates from February.



 On Mon, Jun 11, 2012 at 6:17 PM, Brendan Eich bren...@mozilla.org wrote:
 I thought so too, but Charles is arguing both (a) no worse than today (not 
 better than today); (b) useful for people who prefer
 non-strict code and a more useful stack-tracing API in the core language.

 Just to clarify, I prefer *some* of the ideas behind use strict and
 in fact we built a subset of use strict into our in-house tools long
 before JSLint existed.

 But if it's going to impose a security boundary between my own methods
 and reduce the utility of stack traces which are sometimes the only
 thing you have to go on.. no thank you.  That seems to me to conflate
 useful error checking and security; there is overlap, but not 100%
 overlap by any means.

How do getStack and @privileged reduce the utility of stack traces?
Regarding access to arguments, depending on how much privilege
@privileged should give (see questions at end of my previous email),
it is conceivable that it should give access to strict arguments as
well. Or that there be an @turbo_privileged that grants this
additional level of access. Until we have some experience using the
module system on both browser and server, these issues are hard to
think about.

-- 
    Cheers,
    --MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Andreas Rossberg]

On 12 June 2012 01:36, Charles Kendrick char...@isomorphic.com wrote:
 Your point about not violating use strict or elaborating too much is good,
 but I want to push back on one thing: local vars may be a bridge too far,
 especially with optimizing JITs, block-scoped let bindings, etc. Making
 arguments available is easier.

 I definitely recognize that making local vars available is
 different-in-kind from making function arguments available.  However I
 would ideally like to see it mentioned in the spec with recommended
 but not required wording.

I would also push back very hard on this. Besides semantic issues, it
would screw compilers, because (among other things) it requires
extending liveness of all local variables till the end of their scope
(or at least till after its last impure operation). The effect on
performance would be significant, I'm sure.

Recommended but not required gives you the worst of both worlds: the
user cannot rely on the feature, and the implementer is not relieved
from the pressure to eventually implement it anyway.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Brendan Eich]

Mark S. Miller wrote:

I'm not yet arguing that or the opposite, rather, I'm confused about
what non-strict-only means in this context. Actual stacks consist of
a mixture of strict and non-strict activations.


This isn't so in personal projects or even all-homegrown products or 
shared projects that eschew use strict, as Charles wrote.



  How would the proposed API deal with that?


Eliding strict frames' arguments, Charles wrote.

I objected that this makes any such stack trace API hard to use in the 
large, compared to an information-leaking string-valued .stack approach.


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Charles Kendrick]

On Tue, Jun 12, 2012 at 5:19 AM, Mark S. Miller erig...@google.com wrote:
 On Tue, Jun 12, 2012 at 10:14 AM, Charles Kendrick
 char...@isomorphic.com wrote:
 The only way I can see this working is if there is a way for a given
 piece of code to trap an error and ask some kind of (elevated
 privilege) logging system to provide diagnostic information that a
 (privileged) end user can see.

 I'm not sure what you mean by trap to an error,

My actual words were to trap an error so that probably explains the
confusion :)

 but the rest of your
 description seems close to how SES's console.log, console.warn, etc
 work. They are endowed with access to the privileged getStack function
 and use it to display stack traces on the console's output. See
 http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/logger.js#28
 http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/logger.js#157
 http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/useHTMLLogger.js#116

Yes, this is the pattern I had in mind.  This also means there would
be no need to worry about exposing too much information in a stack
trace.

  It also seems like, in addition to
 this, you should be able to get to stack information programmatically
 so long as you stay within your module or modules that have the same
 privilege.

 If we're talking about code with some privilege to see some stacks,
 why not reify such privilege in a getStack function importable from
 some @privileged module?

I don't have an objection to this being treated as an import.

 This doesn't sound like something that could be reasonably
 standardized into ECMAScript in the near future, and, without all
 those pieces in place, it doesn't seem like ECMAScript should just
 disallow the ability to get stack traces.

 In this thread, we've already considered APIs other than .stack.
 Given anything else, why is getStack(err) is any worse than
 introducing a novel property name?

There's no problem with the API being changed to a getter method as
opposed to error.stack / error.stackFrames.

It would be a problem for access to a stack trace to require @import
or other features that are not yet present in all mainstream browsers.
 If browser implementers cannot add this feature to engines which are
basically only ES4/5, it's not going to be usable for mainstream code
until 2019 or something - in reality, non-standard APIs will continue
to be implemented and used.

 Regarding near future, any such proposal -- whether .stack,
 getStack, or whatever -- has already missed the boat for ES6. getStack
 certainly could be considered in an ES7 timeframe.

Fortunately, these milestones have little to do with when features
appear in browsers.  And this is one of those features where it's
valuable the moment it appears in just one browser.

All we really need is clear consensus, so as to influence browser
vendors' existing efforts in this area.

 Just to clarify, I prefer *some* of the ideas behind use strict and
 in fact we built a subset of use strict into our in-house tools long
 before JSLint existed.

 But if it's going to impose a security boundary between my own methods
 and reduce the utility of stack traces which are sometimes the only
 thing you have to go on.. no thank you.  That seems to me to conflate
 useful error checking and security; there is overlap, but not 100%
 overlap by any means.

 How do getStack and @privileged reduce the utility of stack traces?

They don't.  The above discussion is about use strict and is not about SES.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Charles Kendrick]

On Sat, Jun 9, 2012 at 12:26 PM, Brendan Eich bren...@mozilla.org wrote:
 We do not want a
 non-debugger API that works only some of the time.

What we want (IMO) is an API that allows runtime diagnostics to be collected.

By necessity, function arguments would be unavailable for some stack frames.

This is not a new situation or a flaw in the proposal, it's a
situation which exists already for the function.arguments API.

 Debuggers, in contrast,
 must be able to pierce the veil of use strict.

Clearly.

 A debugger API is further off from standardization. Mozilla has a new one: ...

This is great but pretty much unrelated - clearly we shouldn't cripple
a runtime diagnostic API because there's a debugger API - these are
two different use cases.

Let's get concrete here - because function.arguments is actually
available but not exposed by error.stack, we have implemented a system
that parses error.stack, using its information to find live function
instances, grabs the arguments and receiver from those and injects
them into a new, enhanced stack trace which we log.

And of course we have to cover the recursive case and show the
arguments as not available..

Because runtime diagnostic information like this is so critical,
you'll see this approach being taken by a bunch of frameworks - don't
you find this distasteful and a clear indication that the standard
should be exposing this information directly?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Brendan Eich]

Charles Kendrick wrote:

On Sat, Jun 9, 2012 at 12:26 PM, Brendan Eichbren...@mozilla.org  wrote:

We do not want a
non-debugger API that works only some of the time.


What we want (IMO) is an API that allows runtime diagnostics to be collected.

By necessity, function arguments would be unavailable for some stack frames.

This is not a new situation or a flaw in the proposal, it's a
situation which exists already for the function.arguments API.


It seems to me we've lost the thread (maybe you haven't, but I have -- 
apologies for revisiting). I replied because of this flow:


CK: Erik how do you reconcile this with the fact that this information 
can already be obtained in most production browsers via stack walking?


EA: Stack walking is not available in strict functions

CK: Interesting, but it doesn't speak against programmatic access to the 
call stack.


At this point I'm not sure what you want -- object references to calling 
functions? You're right that we could disclose those where use strict 
does not poison function.arguments and arguments.callee already, but to 
what end? Erik's proposal was about standardizing a string-valued .stack 
property.


If we can't have a common string-valued .stack property, we could still 
make a new one (.stackString or some such; yech) that doesn't include 
object references.


Is there a strong motivation for sometimes exposing (where use strict 
allows) object references, or would your use-cases be met by some better 
string-valued spec?


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Charles Kendrick]

 It seems to me we've lost the thread (maybe you haven't, but I have --
 apologies for revisiting).

In a nutshell, I'm looking for access to function arguments, the
receiver, and ideally even local variable values via *some* runtime
diagnostic API.

These could be all be exposed in an error.stack String or in a more OO
API (say, error.stackFrames as an array of objects with various
properties).

I think the best solution is to have *both*.  In the field right now,
error.stack is a String.  Adding error.stackFrames this would mean:

1. we avoid breaking code in the field

2. we provide a convenient error.stack for people who don't want to
deal with error.stackFrames

3. we avoid people who want to add richer information having to parse
an error.stack String

4. we eliminate all the issues we're running into in trying to
standardize error.stack; it wouldn't be so important for it to expose
more information or have really smart formatting rules like I
previously proposed [1].  It would no longer need to be machine
parsable.  It might even be OK for it's format to remain completely
unspecified since it's just a convenience.

The confusing bit: Erik objected to making arguments available in
error.stack for security reasons, and Erik is correct that use
strict implies arguments would not be available in that case.

However, I see no issue with error.stack or an error.stackFrames API
providing function arguments *only when allowed*; it's not a new
security issue or a new burden on browser / VM implementers since they
must already correctly implement security checks for the equivalent
function.arguments API.

[1] https://mail.mozilla.org/pipermail/es-discuss/2012-June/023247.html


On Mon, Jun 11, 2012 at 12:57 PM, Brendan Eich bren...@mozilla.org wrote:
 Charles Kendrick wrote:

 On Sat, Jun 9, 2012 at 12:26 PM, Brendan Eichbren...@mozilla.org  wrote:

 We do not want a
 non-debugger API that works only some of the time.


 What we want (IMO) is an API that allows runtime diagnostics to be
 collected.

 By necessity, function arguments would be unavailable for some stack
 frames.

 This is not a new situation or a flaw in the proposal, it's a
 situation which exists already for the function.arguments API.


 It seems to me we've lost the thread (maybe you haven't, but I have --
 apologies for revisiting). I replied because of this flow:

 CK: Erik how do you reconcile this with the fact that this information can
 already be obtained in most production browsers via stack walking?

 EA: Stack walking is not available in strict functions

 CK: Interesting, but it doesn't speak against programmatic access to the
 call stack.

 At this point I'm not sure what you want -- object references to calling
 functions? You're right that we could disclose those where use strict does
 not poison function.arguments and arguments.callee already, but to what end?
 Erik's proposal was about standardizing a string-valued .stack property.

 If we can't have a common string-valued .stack property, we could still make
 a new one (.stackString or some such; yech) that doesn't include object
 references.

 Is there a strong motivation for sometimes exposing (where use strict
 allows) object references, or would your use-cases be met by some better
 string-valued spec?

 /be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Brendan Eich]

I have a sinking feeling it may be better to do just error.stackFrames, 
the new object/number/string lazy stack-trace reflection. We can model 
it on the union of error.stack implementations in the field, so those 
could be reimplemented under/on-top-of error.stackFrames. But we'll have 
no compatibility problems to sort out, and fewer complaints about the 
string-valued property (it may be fine to remain underspecified or 
unspecified).


Your point about not violating use strict or elaborating too much is 
good, but I want to push back on one thing: local vars may be a bridge 
too far, especially with optimizing JITs, block-scoped let bindings, 
etc. Making arguments available is easier.


Erik, what do you think?

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Mark S. Miller]

On Tue, Jun 12, 2012 at 7:12 AM, Brendan Eich bren...@mozilla.org wrote:
 Your point about not violating use strict or elaborating too much is good,
 but I want to push back on one thing: local vars may be a bridge too far,
 especially with optimizing JITs, block-scoped let bindings, etc. Making
 arguments available is easier.

Revealing secrets passed in arguments? C'mon. Making arguments
*generally* available would be fatal. That's why you need something
like the getStack function I suggested earlier: debugging info is
accessed only by rights amplification, and the amplifier is not made
generally available.



 Erik, what do you think?


 /be
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss



-- 
    Cheers,
    --MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Charles Kendrick]

 Your point about not violating use strict or elaborating too much is good,
 but I want to push back on one thing: local vars may be a bridge too far,
 especially with optimizing JITs, block-scoped let bindings, etc. Making
 arguments available is easier.

I definitely recognize that making local vars available is
different-in-kind from making function arguments available.  However I
would ideally like to see it mentioned in the spec with recommended
but not required wording.

However what about receivers / this value?  That seems to me to be
more in the realm of function arguments, and reasonable to require.
As I mentioned previously, this is available from Chrome's
JavaScriptStackTrace API, but not for a function defined with use
strict.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Mark S. Miller]

On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eich bren...@mozilla.org wrote:
 Also, as you pointed out, even error.stack leaks information. Where do you
 draw the line?

Conservatively. I suggest that there be no error.stack, but rather
getStack(error), in order to avoid this information leak.


 I think Charles was arguing that anyone keeping secrets would need use
 strict to protect those secrets anyway, because otherwise
 arguments.caller.arguments[i] (given non-strict caller and callee) can get
 them.

Non-strict functions should not be assumed to be encapsulated, so it
would be ok if they leaked info in yet more ways. However, a stack
consists of a mixture of strict and non-strict activations, so I don't
see how this helps.


 This is a good argument for Error.getStack(errObj), indeed.

Not Error.getStack. Error is generally available, so if the amplifier
were Error.getStack, it would be generally available too.

This leaves open the question of where to get things that are not
generally available. I hope and expect that we can find good answers
in the module system. The getStack amplifier should be obtained by
importing a module that is not generally importable. We've already
encountered the need for such privileged imports...

From http://wiki.ecmascript.org/doku.php?id=strawman:weak_references:
 Pending an accepted modules proposal, we do not yet specify in what namespace 
 this
 constructor [makeWeakRef] is found. Note that makeWeakRef is not safe for 
 general
 access since it grants access to the non-determinism inherent in observing 
 garbage
 collection. The resulting side channel reveals information that may violate 
 the
 confidentiality assumptions of other programs.

--
    Cheers,
    --MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Charles Kendrick]

On Mon, Jun 11, 2012 at 4:51 PM, Mark S. Miller erig...@google.com wrote:
 On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eich bren...@mozilla.org wrote:
 I think Charles was arguing that anyone keeping secrets would need use
 strict to protect those secrets anyway, because otherwise
 arguments.caller.arguments[i] (given non-strict caller and callee) can get
 them.

 Non-strict functions should not be assumed to be encapsulated, so it
 would be ok if they leaked info in yet more ways. However, a stack
 consists of a mixture of strict and non-strict activations, so I don't
 see how this helps.

It helps because, whether we are talking about a String API or an OO
API, you make available arguments for non-strict functions, whereas
for strict functions you do not.

This doesn't expose any more information than is already exposed by
function.arguments.

This means a library using use strict and passing a secret to a
non-strict function might have that secret revealed, and this is,
again, already the case today (via function.arguments).

 This is a good argument for Error.getStack(errObj), indeed.

 Not Error.getStack. Error is generally available, so if the amplifier
 were Error.getStack, it would be generally available too.

 This leaves open the question of where to get things that are not
 generally available. I hope and expect that we can find good answers
 in the module system. The getStack amplifier should be obtained by
 importing a module that is not generally importable. We've already
 encountered the need for such privileged imports...

I'm reading this as saying that stack traces in general should not be
available unless the code is privileged in some way.  This can't be
what you mean, so could you clarify?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Erik Arvidsson]

On Mon, Jun 11, 2012 at 4:12 PM, Brendan Eich bren...@mozilla.org wrote:
 I have a sinking feeling it may be better to do just error.stackFrames, the
 new object/number/string lazy stack-trace reflection. We can model it on the
 union of error.stack implementations in the field, so those could be
 reimplemented under/on-top-of error.stackFrames. But we'll have no
 compatibility problems to sort out, and fewer complaints about the
 string-valued property (it may be fine to remain underspecified or
 unspecified).

 Your point about not violating use strict or elaborating too much is good,
 but I want to push back on one thing: local vars may be a bridge too far,
 especially with optimizing JITs, block-scoped let bindings, etc. Making
 arguments available is easier.

 Erik, what do you think?

Yes, at this point I'm also convince that we should provide a new
property that provides structured information of the stack trace and
not specify Error stack at all.

-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Mark S. Miller]

On Tue, Jun 12, 2012 at 7:59 AM, Charles Kendrick
char...@isomorphic.com wrote:
 I'm reading this as saying that stack traces in general should not be
 available unless the code is privileged in some way.  This can't be
 what you mean, so could you clarify?

That is exactly what I mean.


-- 
    Cheers,
    --MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Brendan Eich]

Mark S. Miller wrote:

On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eichbren...@mozilla.org  wrote:

Also, as you pointed out, even error.stack leaks information. Where do you
draw the line?


Conservatively. I suggest that there be no error.stack, but rather
getStack(error), in order to avoid this information leak.


With some kind of

  import getStack from @reflect;

or similar, and SES uses a custom loader to censor @reflect?


I think Charles was arguing that anyone keeping secrets would need use
strict to protect those secrets anyway, because otherwise
arguments.caller.arguments[i] (given non-strict caller and callee) can get
them.


Non-strict functions should not be assumed to be encapsulated, so it
would be ok if they leaked info in yet more ways. However, a stack
consists of a mixture of strict and non-strict activations, so I don't
see how this helps.


I thought so too, but Charles is arguing both (a) no worse than today 
(not better than today); (b) useful for people who prefer non-strict 
code and a more useful stack-tracing API in the core language.


This is a matter of preference, not necessity, if we're talking about 
the language as it is. We won't be making use strict the default. We 
are trying to avoid more modes (1JS). We're not talking about SES. So I 
don't see how it can be argued logically that a non-strict-only 
arguments-disclosing stack-tracing API is either never helpful nor 
always helpful. YMMV.



This is a good argument for Error.getStack(errObj), indeed.


Not Error.getStack. Error is generally available, so if the amplifier
were Error.getStack, it would be generally available too.

This leaves open the question of where to get things that are not
generally available. I hope and expect that we can find good answers
in the module system. The getStack amplifier should be obtained by
importing a module that is not generally importable. We've already
encountered the need for such privileged imports...

Fromhttp://wiki.ecmascript.org/doku.php?id=strawman:weak_references:

Pending an accepted modules proposal, we do not yet specify in what namespace 
this
constructor [makeWeakRef] is found. Note that makeWeakRef is not safe for 
general
access since it grants access to the non-determinism inherent in observing 
garbage
collection. The resulting side channel reveals information that may violate the
confidentiality assumptions of other programs.


I see -- thanks. We should try to detail the privileged APIs and their 
module(s) a bit more. I used @reflect above but I didn't mean to 
equate it to Tom's Reflect.* used in conjunction with direct proxies. 
And not all reflection facilities are privileged -- more the reverse for 
the direct proxy stuff, right?


/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Charles Kendrick]

On Mon, Jun 11, 2012 at 5:55 PM, Mark S. Miller erig...@google.com wrote:
 On Tue, Jun 12, 2012 at 7:59 AM, Charles Kendrick
 char...@isomorphic.com wrote:
 I'm reading this as saying that stack traces in general should not be
 available unless the code is privileged in some way.  This can't be
 what you mean, so could you clarify?

 That is exactly what I mean.

The only way I can see this working is if there is a way for a given
piece of code to trap an error and ask some kind of (elevated
privilege) logging system to provide diagnostic information that a
(privileged) end user can see.  It also seems like, in addition to
this, you should be able to get to stack information programmatically
so long as you stay within your module or modules that have the same
privilege.

This doesn't sound like something that could be reasonably
standardized into ECMAScript in the near future, and, without all
those pieces in place, it doesn't seem like ECMAScript should just
disallow the ability to get stack traces.

Brendan brought up SES - I know little about it, but for its sake I
hope this critical use case is taken into account.

On Mon, Jun 11, 2012 at 6:17 PM, Brendan Eich bren...@mozilla.org wrote:
 I thought so too, but Charles is arguing both (a) no worse than today (not 
 better than today); (b) useful for people who prefer
 non-strict code and a more useful stack-tracing API in the core language.

Just to clarify, I prefer *some* of the ideas behind use strict and
in fact we built a subset of use strict into our in-house tools long
before JSLint existed.

But if it's going to impose a security boundary between my own methods
and reduce the utility of stack traces which are sometimes the only
thing you have to go on.. no thank you.  That seems to me to conflate
useful error checking and security; there is overlap, but not 100%
overlap by any means.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Tom Van Cutsem]

2012/6/12 Brendan Eich bren...@mozilla.org

 I see -- thanks. We should try to detail the privileged APIs and their
 module(s) a bit more. I used @reflect above but I didn't mean to equate
 it to Tom's Reflect.* used in conjunction with direct proxies. And not all
 reflection facilities are privileged -- more the reverse for the direct
 proxy stuff, right?


That's right. The reflection API specced at 
http://wiki.ecmascript.org/doku.php?id=harmony:reflect_api was meant to
encapsulate both proxies and all the utility methods that a proxy handler
needs to uniformly forward trapped ops to a target object. AFAICT, none
of these operations are privileged: it's easy enough to define them in
terms of more primitive, immediately available JS built-ins/operators.

Cheers,
Tom
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Geoffrey Sneddon]

On 07/06/12 21:12, Jason Orendorff wrote:

On Thu, Jun 7, 2012 at 1:37 PM, Erik Arvidssonerik.arvids...@gmail.com  wrote:

  I wrote a new strawman for Error stack which is now available in some
  form in all major browser (if betas are considered).

  http://wiki.ecmascript.org/doku.php?id=strawman:error_stack

  Feedback wanted.

This isn't machine parseable in all cases, since the .message may
contain newlines and can end with something like \n  at ...

Changing this in Firefox would affect any Firefox addons that use
Error.stack, but maybe we can take that hit.


It's not just Firefox addons that will break: GWT's output relies upon 
the exact format of Error.stack[1]. I know Google Wave depended upon 
this, and I believe other Google applications do too.


As such, I'm somewhat dubious as to whether we can actually change the 
format that much without breaking sites. For reference, we support 
Error.stack (supposedly identical to SpiderMonkey in format, though 
obviously not) and Error.stacktrace (which is meant to actually be human 
readable). Originally, we had Error.stacktrace as Error.stack, but it 
just broke too much (we spoof UA on some Google sites by default, and 
have to choose whether to go down IE/Fx/WK code-path, and often all 
three rely upon non-standard behaviour).


[1]: 
http://code.google.com/p/google-web-toolkit/source/browse/releases/2.4/user/src/com/google/gwt/core/client/impl/StackTraceCreator.java


--
Geoffrey Sneddon — Opera Software
http://gsnedders.com
http://opera.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Erik Arvidsson]

On Sun, Jun 10, 2012 at 6:56 AM, Geoffrey Sneddon gsned...@opera.com wrote:
 As such, I'm somewhat dubious as to whether we can actually change the
 format that much without breaking sites. For reference, we support
 Error.stack (supposedly identical to SpiderMonkey in format, though
 obviously not) and Error.stacktrace (which is meant to actually be human
 readable). Originally, we had Error.stacktrace as Error.stack, but it just
 broke too much (we spoof UA on some Google sites by default, and have to
 choose whether to go down IE/Fx/WK code-path, and often all three rely upon
 non-standard behaviour).

 [1]:
 http://code.google.com/p/google-web-toolkit/source/browse/releases/2.4/user/src/com/google/gwt/core/client/impl/StackTraceCreator.java

This looks pretty broken to me as is. It does not seem to work correct
for the V8 style formatting that is used by Chrome and IE.

The thing is that software on the open web has to handle two different
formattings already to work correctly. The reason I picked the V8
style over the SpiderMonkey style is that the SpiderMonkey style is
missing essential information like the column number which is a must
these days. If we change the SpiderMonkey format we now have 3
incompatible formattings which is even worse.

We could give up on the stack property and introduce a new property
that does not require parsing a string.

-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[T.J. Crowder]

On 10 June 2012 22:31, Erik Arvidsson erik.arvids...@gmail.com wrote:

 The thing is that software on the open web has to handle two different
 formattings already to work correctly. The reason I picked the V8
 style over the SpiderMonkey style is that the SpiderMonkey style is
 missing essential information like the column number which is a must
 these days. If we change the SpiderMonkey format we now have 3
 incompatible formattings which is even worse.

 We could give up on the stack property and introduce a new property
 that does not require parsing a string.


FWIW, speaking as Joe Developer, if it's really true that the current
state of affairs is that there is no robust commonality, that would seem to
be the appropriate way forward.

-- T.J.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Oliver Hunt]

My original implementation in JSC was as an Array, but I found that there were 
sites that depended on .stack being a string if it was present.  Any form of 
string encoding we expect to be machine parseable by necessity will require 
escaping and full format description.  I've actually been tempted to switch 
JSC's current icky format into JSON on the basis that JSON is already well 
defined, and everyone has fast encoders and decoders for JSON these days.

--Oliver

On Jun 10, 2012, at 2:31 PM, Erik Arvidsson wrote:

 On Sun, Jun 10, 2012 at 6:56 AM, Geoffrey Sneddon gsned...@opera.com wrote:
 As such, I'm somewhat dubious as to whether we can actually change the
 format that much without breaking sites. For reference, we support
 Error.stack (supposedly identical to SpiderMonkey in format, though
 obviously not) and Error.stacktrace (which is meant to actually be human
 readable). Originally, we had Error.stacktrace as Error.stack, but it just
 broke too much (we spoof UA on some Google sites by default, and have to
 choose whether to go down IE/Fx/WK code-path, and often all three rely upon
 non-standard behaviour).
 
 [1]:
 http://code.google.com/p/google-web-toolkit/source/browse/releases/2.4/user/src/com/google/gwt/core/client/impl/StackTraceCreator.java
 
 This looks pretty broken to me as is. It does not seem to work correct
 for the V8 style formatting that is used by Chrome and IE.
 
 The thing is that software on the open web has to handle two different
 formattings already to work correctly. The reason I picked the V8
 style over the SpiderMonkey style is that the SpiderMonkey style is
 missing essential information like the column number which is a must
 these days. If we change the SpiderMonkey format we now have 3
 incompatible formattings which is even worse.
 
 We could give up on the stack property and introduce a new property
 that does not require parsing a string.
 
 -- 
 erik
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[T.J. Crowder]

On 10 June 2012 22:44, Oliver Hunt oli...@apple.com wrote:

 My original implementation in JSC was as an Array, but I found that there
 were sites that depended on .stack being a string if it was present.  Any
 form of string encoding we expect to be machine parseable by necessity will
 require escaping and full format description.  I've actually been tempted
 to switch JSC's current icky format into JSON on the basis that JSON is
 already well defined, and everyone has fast encoders and decoders for JSON
 these days.


Wouldn't changing the existing format of the string break existing code
without offering any real benefit over continuing the existing format of
that string (for now) but adding a new structured property that code could
take advantage of? Not seeing much point in the browser generating JSON
that just has to be decoded by anyone who wants to use it (fast or not).

-- T.J.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Oliver Hunt]

There's no real consistency between any implementations of .stack.  The only 
reason it needs to be a string is so that sites that blindly use .split() on it 
don't throw an exception.

If you used JSON you could do the following output:
{message:...,trace:[
{source:..., line:...},
{source:..., line:...},
{source:..., line:...},
...
]}

.split(\n) would provide a analogous result to the equivalent on current 
formats, with the added advantage of having automatically escaped anything that 
needs escaping (so each line in the trace would be guaranteed to be one line.

Better yet, because you're just saying use JSON it becomes perfectly possible 
to add additional fields (function name, inferred name, arguments, type,... 
whatever) without requiring re-specifying the format, or trying to add new 
fields without breaking existing parsers.

Note: this is just if we wanted to use .stack -- my original implementation was 
prefixed and just produced an array iirc, but i was convinced to use .stack so 
sites wouldn't have to manually select the stack property to use.  This then 
broke many big sites that always do .split() on .stack, which didn't work as 
the result was not a string.  Yay!

--Oliver

On Jun 10, 2012, at 2:49 PM, T.J. Crowder wrote:

 On 10 June 2012 22:44, Oliver Hunt oli...@apple.com wrote:
 My original implementation in JSC was as an Array, but I found that there 
 were sites that depended on .stack being a string if it was present.  Any 
 form of string encoding we expect to be machine parseable by necessity will 
 require escaping and full format description.  I've actually been tempted to 
 switch JSC's current icky format into JSON on the basis that JSON is already 
 well defined, and everyone has fast encoders and decoders for JSON these days.
 
 Wouldn't changing the existing format of the string break existing code 
 without offering any real benefit over continuing the existing format of that 
 string (for now) but adding a new structured property that code could take 
 advantage of? Not seeing much point in the browser generating JSON that just 
 has to be decoded by anyone who wants to use it (fast or not).
 
 -- T.J. 
 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[John Tamplin]

On Sun, Jun 10, 2012 at 5:31 PM, Erik Arvidsson erik.arvids...@gmail.comwrote:

 On Sun, Jun 10, 2012 at 6:56 AM, Geoffrey Sneddon gsned...@opera.com
 wrote:
  As such, I'm somewhat dubious as to whether we can actually change the
  format that much without breaking sites. For reference, we support
  Error.stack (supposedly identical to SpiderMonkey in format, though
  obviously not) and Error.stacktrace (which is meant to actually be human
  readable). Originally, we had Error.stacktrace as Error.stack, but it
 just
  broke too much (we spoof UA on some Google sites by default, and have to
  choose whether to go down IE/Fx/WK code-path, and often all three rely
 upon
  non-standard behaviour).
 
  [1]:
 
 http://code.google.com/p/google-web-toolkit/source/browse/releases/2.4/user/src/com/google/gwt/core/client/impl/StackTraceCreator.java

 This looks pretty broken to me as is. It does not seem to work correct
 for the V8 style formatting that is used by Chrome and IE.


Note that GWT uses deferred binding to substitute browser-specific
implementations for the version being compiled -- see
http://code.google.com/p/google-web-toolkit/source/browse/releases/2.4/user/src/com/google/gwt/core/CoreWithUserAgent.gwt.xml
where
the mappings are defined.  So, for Chrome, CollectorChrome is used instead
of Collector.

-- 
John A. Tamplin
Software Engineer (GWT), Google
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[John Tamplin]

On Sun, Jun 10, 2012 at 9:56 AM, Geoffrey Sneddon gsned...@opera.comwrote:

 It's not just Firefox addons that will break: GWT's output relies upon the
 exact format of Error.stack[1]. I know Google Wave depended upon this, and
 I believe other Google applications do too.


Note that GWT can supply different deferred-bound implementations for
different browsers, though generally we do runtime detection rather than
compile time if there are few differences between versions.  Of course,
that would only affect deployed apps if they recompiled, but I wouldn't
expect that would be much of a problem for any currently maintained apps.

-- 
John A. Tamplin
Software Engineer (GWT), Google
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Mark S. Miller]

 Oliver Hunt wrote:
 [...] If you used JSON [...]


On Mon, Jun 11, 2012 at 6:35 AM, Brendan Eich bren...@mozilla.org wrote:
 The easy way out is Error.prototype.stackTrace, a getter that exposes,
 deeply and lazily, objects with string and number valued properties cleanly
 reflecting the desired information -- and without any capability leaks.

 At this point, perhaps better is better. Any such stackTrace spec should not
 diverge too far from the various .stack implementations, in that one should
 be able to construct the latter from the fomer one true .stackTrace or
 .stackFrames or whatever it must be called.

http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#63

getCWStack(err) returns a JSON-able representation, but only to those
that possess the getCWStack function, which is not generally
available, as that would be a bad information leak (though still not a
capability leak). getStack(err) at
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#204
turns this back into a v8-like stack description string, but again
only to those that possess the getStack function (which should be
co-available with getCWStack). The overall debug.js file is a SES shim
for retrofitting this behavior securely onto v8 and, to varying
degrees, other browsers

-- 
    Cheers,
    --MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Charles Kendrick]

On Fri, Jun 8, 2012 at 6:48 PM, Erik Arvidsson erik.arvids...@gmail.com wrote:
 On Fri, Jun 8, 2012 at 4:10 PM, Charles Kendrick char...@isomorphic.com 
 wrote:
 Once again, exposing the actual arguments, receiver and function
 object references is a security issue and completely out of scope for
 this. This is not related to cross domain access but related to object
 capabilities.

 Erik how do you reconcile this with the fact that this information can
 already be obtained in most production browsers via stack walking?

 Stack walking is not available in strict functions.

Interesting, but it doesn't speak against programmatic access to the
call stack.

If use strict or any other security feature means that
function.arguments are not accessible to a given script, then the same
constraint could be trivially enforced with programmatic access to the
call stack.

The same could be applied to access to the receiver or values of local
variables.  In fact, V8's CallSite API makes the receiver inaccessible
for a strict mode function (I just checked).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Brendan Eich]

Charles Kendrick wrote:

On Fri, Jun 8, 2012 at 6:48 PM, Erik Arvidssonerik.arvids...@gmail.com  wrote:

On Fri, Jun 8, 2012 at 4:10 PM, Charles Kendrickchar...@isomorphic.com  wrote:

Once again, exposing the actual arguments, receiver and function
object references is a security issue and completely out of scope for
this. This is not related to cross domain access but related to object
capabilities.

Erik how do you reconcile this with the fact that this information can
already be obtained in most production browsers via stack walking?

Stack walking is not available in strict functions.


Interesting, but it doesn't speak against programmatic access to the
call stack.


But you wrote how do you reconcile and Erik answered. We do not want a 
non-debugger API that works only some of the time. Debuggers, in 
contrast, must be able to pierce the veil of use strict.


Erik's proposal is for the string-valued .stack property.

A debugger API is further off from standardization. Mozilla has a new one:

Video: http://www.youtube.com/watch?v=WKIkOcuVG7w

https://wiki.mozilla.org/JSInspector
https://wiki.mozilla.org/Remote_Debugging_Protocol
https://wiki.mozilla.org/DevTools/Features/Debugger/Notes

This is in Firefox Nightlies now.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Wes Garland]

error.stackFrames, an Array which contains one object per stack frame,
describing function name (if any), filename, line number, some kind of
instance Id (for closures), arguments, and closed-over variables would
be absolutely incredible from my POV.

Tie it up in a nice package that can be JSON.stringified, and that SSJS
back-ends can send better debug info back to the browser for the developers
to consume.

Wes

On 8 June 2012 02:57, T.J. Crowder t...@crowdersoftware.com wrote:

 On 8 June 2012 04:28, David Herman dher...@mozilla.com wrote:

 - You mentioned that compatibility requires error.stack to be a string,
 even though programs would really like to have a structured version. Should
 we offer a different property with structured stack frame info (probably
 with a getter to allow straight-forward lazy construction), called
 error.stackFrames or error.stackEntries or something?


 Big +1 on that. Avoiding parsing information the engine has as discrete
 items already is a Good Thing(tm). Perhaps it'll be aspirational at first,
 but if specified now it'll happen eventually.

 -- T.J.

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss




-- 
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Erik Arvidsson]

On Thu, Jun 7, 2012 at 3:21 PM, Charles Kendrick char...@isomorphic.com wrote:
 I agree that something like error.stackFrames would be ideal.  However
 I would say the V8 stack trace API is missing 3 key things:

 1. access to parameter values
 2. access to local variables defined in the function
 3. access to the line of code that crashed / called the next frame

One thing that might not have been as clear as I wanted is that this
is trying to spec Error stack as it exists today. This is not intended
to cover any kind of debugging APIs. That is a completely different
topic and has a lot of security implications.

-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Erik Arvidsson]

On Thu, Jun 7, 2012 at 11:57 PM, T.J. Crowder t...@crowdersoftware.com wrote:
 On 8 June 2012 04:28, David Herman dher...@mozilla.com wrote:

 - You mentioned that compatibility requires error.stack to be a string,
 even though programs would really like to have a structured version. Should
 we offer a different property with structured stack frame info (probably
 with a getter to allow straight-forward lazy construction), called
 error.stackFrames or error.stackEntries or something?


 Big +1 on that. Avoiding parsing information the engine has as discrete
 items already is a Good Thing(tm). Perhaps it'll be aspirational at first,
 but if specified now it'll happen eventually.

There has been some interest in trying to align the existing Error
stack property and this proposal is about that.

Could we provide a new better alternative API? Of course. Feel free to
come up with another proposal.

-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Alex Vincent]

 -- Forwarded message --
 From: Erik Arvidsson erik.arvids...@gmail.com
 To: es-discuss@mozilla.org
 Cc:
 Date: Thu, 7 Jun 2012 11:37:41 -0700
 Subject: Error stack
 I wrote a new strawman for Error stack which is now available in some
 form in all major browser (if betas are considered).

 http://wiki.ecmascript.org/doku.php?id=strawman:error_stack

 Feedback wanted.


As the person who originally proposed the stack property to Mozilla over
ten years ago, I am absolutely thrilled to see this as a strawman on
Harmony.  In any form.

For reference, the original bug is at
https://bugzilla.mozilla.org/show_bug.cgi?id=123177 .

The only thing I might ask is to keep the ability to alter the stack - in a
controlled way.  Specifically, I've had occasion to want to remove the
first two or three frames of an error stack, because I was implementing an
assert() function.  When the assert failed, I wanted the stack to start at
the actual line of the assert call, instead of a couple of lines away (new
Error(), then the assert function, and then the caller of assert).  That
said, I'd understand if the Harmony working group rejected this and
required the property be read-only and never changeable.

Alex Vincent
-- 
The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own.
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Charles Kendrick]

On Fri, Jun 8, 2012 at 5:38 AM, Patrick Mueller pmue...@gmail.com wrote:
 Personally, I'm happy with a user-land way of being able to generate
 something like this, in V8:

     https://gist.github.com/312a55532fac0296f2ab

You can actually do this now in userland in Chrome (except the
CoffeeScript aspect).  This link was posted yesterday:

 http://code.google.com/p/v8/wiki/JavaScriptStackTraceApi

.. but I've subsequently commented on the page with some working code
since people were having trouble understanding how to get to the array
of CallSite objects (it's a pretty bizarre API).

 If there's issues dealing with recursion, or whatever, fine, just tell me
 what they are.

You can't get to function arguments for recursive functions (appears
more than once on stack).  I filed this bug on it, perhaps you'd like
to star it:

http://code.google.com/p/v8/issues/detail?id=2169

Note: Erik just mentioned in passing that debugging APIs have security
implications - this is potentially true for local variable access, but
JavaScript VMs already have to handle correct security for access to
function arguments due to the existing  function.arguments API.  So
nothing new there in terms of risk or burden on the browser
implementer.

 I think that getting access to parm values/locals is interesting, but
 veering into the land of the debugger.

Just to connect the dots, as I said previously, you don't have a
debugger when you are looking at logs for an application you can't
access.  Programmatic access to this information is critical in that
use case, but also extremely valuable just everyday - how many times
have you seen an application get into an error state that you aren't
sure how to reproduce, when you didn't happen to be in the debugger?
If you had robust stack traces you'd have a lot more to go on.

With IE6 we solved dozens of bugs just from stack trace information.
Ah the good old days!  (yes that's sarcasm + irony)

 I'd prefer a clean take on
 debugging APIs rather than evolve it from an exception back-trace use
 case.  When do we start talking about that?  I'm looking at you,
 --expose_debug_as (V8 option).

An Array of StackFrame / CallSite objects is pretty much a clean
debugging API and not really something grafted on.  The same concept
appears in most debug APIs, eg Java's:


http://docs.oracle.com/javase/1.4.2/docs/guide/jpda/jdi/com/sun/jdi/StackFrame.html

 --
 Patrick Mueller
 http://muellerware.org
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Brandon Benvie]

You can get the arguments. Here's an example of getting more info out of a
try..catch: https://gist.github.com/2898384

Which results in error.stack being an array of objects like (function,
arguments, and receiver are actual function/array/object)

{
  function: function,
  name: InjectedScript._evaluateOn,
  inferredName: _evaluateOn,
  arguments: Array[5],
  invocationType: call,
  receiver: receiver,
  inferredType: Object,
  origin: undefined,
  column: 33,
  line: 343,
  position: 12853,
  type: file
};
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Erik Arvidsson]

On Fri, Jun 8, 2012 at 3:25 PM, Brandon Benvie
bran...@brandonbenvie.com wrote:
 You can get the arguments. Here's an example of getting more info out of a
 try..catch: https://gist.github.com/2898384

 Which results in error.stack being an array of objects like (function,
 arguments, and receiver are actual function/array/object)

 {
   function: function,
   name: InjectedScript._evaluateOn,
   inferredName: _evaluateOn,
   arguments: Array[5],
   invocationType: call,
   receiver: receiver,
   inferredType: Object,
   origin: undefined,
   column: 33,
   line: 343,
   position: 12853,
   type: file
 };

Once again, exposing the actual arguments, receiver and function
object references is a security issue and completely out of scope for
this. This is not related to cross domain access but related to object
capabilities.

Here is an example of when this would be a security issue:

function foo(secret) {
  'use strict';
  thirdPartyFunction();
}

...

function thirdPartyFunction() {
  getStackTrace(new Error)[1].arguments[0]; // oops I just leaked the secret.
}

Any proposal that exposes argument values and/or object references are
dead on arrival.

-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Wes Garland]

It might be out of scope, but as a developer, I would almost give my left
nut to have the kind of information in Brendan's example.

Even more so if it the browser guys made it available as an argument to the
window.onerror callback.

Wes

-- 
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Charles Kendrick]

 Once again, exposing the actual arguments, receiver and function
 object references is a security issue and completely out of scope for
 this. This is not related to cross domain access but related to object
 capabilities.

Erik how do you reconcile this with the fact that this information can
already be obtained in most production browsers via stack walking?

Also, forgive my ignorance, but is it an explicit goal of the
JavaScript language that two scripts in a web page from the same
domain must not be able to discover each other's runtime arguments?

On Fri, Jun 8, 2012 at 3:50 PM, Erik Arvidsson erik.arvids...@gmail.com wrote:
 On Fri, Jun 8, 2012 at 3:25 PM, Brandon Benvie
 bran...@brandonbenvie.com wrote:
 You can get the arguments. Here's an example of getting more info out of a
 try..catch: https://gist.github.com/2898384

 Which results in error.stack being an array of objects like (function,
 arguments, and receiver are actual function/array/object)

 {
   function: function,
   name: InjectedScript._evaluateOn,
   inferredName: _evaluateOn,
   arguments: Array[5],
   invocationType: call,
   receiver: receiver,
   inferredType: Object,
   origin: undefined,
   column: 33,
   line: 343,
   position: 12853,
   type: file
 };

 Once again, exposing the actual arguments, receiver and function
 object references is a security issue and completely out of scope for
 this. This is not related to cross domain access but related to object
 capabilities.

 Here is an example of when this would be a security issue:

 function foo(secret) {
  'use strict';
  thirdPartyFunction();
 }

 ...

 function thirdPartyFunction() {
  getStackTrace(new Error)[1].arguments[0]; // oops I just leaked the secret.
 }

 Any proposal that exposes argument values and/or object references are
 dead on arrival.

 --
 erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Charles Kendrick]

No, this doesn't work.

When you are in the catch() block you can discover the arguments for
the function that contains the catch block and for any (non-recursive)
functions further up the stack.  But you cannot discover the arguments
for functions that were on the stack when the error happened, but have
exited by the time you hop back to the catch block.

Your test happens to sidestep this because the catch block is in the
function that throws the error.  But the more important scenario is
that a function somewhere down stack has crashed and you want to see
what the arguments were when the crash occurred - because those are
the arguments most valuable to know from a troubleshooting
perspective.

My test code for the V8 issue demonstrates this problem:

http://code.google.com/p/v8/issues/detail?id=2169

On Fri, Jun 8, 2012 at 3:25 PM, Brandon Benvie
bran...@brandonbenvie.com wrote:
 You can get the arguments. Here's an example of getting more info out of a
 try..catch: https://gist.github.com/2898384

 Which results in error.stack being an array of objects like (function,
 arguments, and receiver are actual function/array/object)

 {
   function: function,
   name: InjectedScript._evaluateOn,
   inferredName: _evaluateOn,
   arguments: Array[5],
   invocationType: call,
   receiver: receiver,
   inferredType: Object,
   origin: undefined,
   column: 33,
   line: 343,
   position: 12853,
   type: file
 };
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Brandon Benvie]

Oh I see, the arguments of the just function that throws is unset. I didn't
get what you were saying at first.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Charles Kendrick]

Almost - there are no arguments for the function that throws, as well as all 
functions between the function that throws and the one that catches.

On Jun 8, 2012, at 4:53 PM, Brandon Benvie bran...@brandonbenvie.com wrote:

 Oh I see, the arguments of the just function that throws is unset. I didn't 
 get what you were saying at first.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Erik Arvidsson]

On Fri, Jun 8, 2012 at 4:10 PM, Charles Kendrick char...@isomorphic.com wrote:
 Once again, exposing the actual arguments, receiver and function
 object references is a security issue and completely out of scope for
 this. This is not related to cross domain access but related to object
 capabilities.

 Erik how do you reconcile this with the fact that this information can
 already be obtained in most production browsers via stack walking?

Stack walking is not available in strict functions.

-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Error stack

[Erik Arvidsson]

I wrote a new strawman for Error stack which is now available in some
form in all major browser (if betas are considered).

http://wiki.ecmascript.org/doku.php?id=strawman:error_stack

Feedback wanted.

-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[John J Barton]

On Thu, Jun 7, 2012 at 11:37 AM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
 I wrote a new strawman for Error stack which is now available in some
 form in all major browser (if betas are considered).

 http://wiki.ecmascript.org/doku.php?id=strawman:error_stack

 Feedback wanted.

You might look at the Mueller format:
https://gist.github.com/312a55532fac0296f2ab

Note that the V8 stack is not a property of the error object but
rather a getter. This is a valuable performance advantage since the
stack is not converted from C++ array to string until the getter is
called.

Critical for tools is the ability to linkify the stack trace so we
need the grammar to allow the URLs to be unambiguously parsable,
including avoiding content of the error message from interfering.

jjb



 --
 erik
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Erik Arvidsson]

On Thu, Jun 7, 2012 at 12:05 PM, John J Barton
johnjbar...@johnjbarton.com wrote:
 On Thu, Jun 7, 2012 at 11:37 AM, Erik Arvidsson
 erik.arvids...@gmail.com wrote:
 I wrote a new strawman for Error stack which is now available in some
 form in all major browser (if betas are considered).

 http://wiki.ecmascript.org/doku.php?id=strawman:error_stack

 Feedback wanted.

 You might look at the Mueller format:
 https://gist.github.com/312a55532fac0296f2ab

 Note that the V8 stack is not a property of the error object but
 rather a getter. This is a valuable performance advantage since the
 stack is not converted from C++ array to string until the getter is
 called.

This is well known. Engines can implement lazy data properties too but
maybe that is too magical. I'm fine speccing this as an accessor but
if it is an accessor we should spec it as on Error.prototype and not
on the instance.

 Critical for tools is the ability to linkify the stack trace so we
 need the grammar to allow the URLs to be unambiguously parsable,
 including avoiding content of the error message from interfering.

Agreed and I believe the V8 format fulfills that requirement.

-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[John Lenz]

It would be great to see this standardized!

On Thu, Jun 7, 2012 at 12:17 PM, Erik Arvidsson erik.arvids...@gmail.comwrote:

 On Thu, Jun 7, 2012 at 12:05 PM, John J Barton
 johnjbar...@johnjbarton.com wrote:
  On Thu, Jun 7, 2012 at 11:37 AM, Erik Arvidsson
  erik.arvids...@gmail.com wrote:
  I wrote a new strawman for Error stack which is now available in some
  form in all major browser (if betas are considered).
 
  http://wiki.ecmascript.org/doku.php?id=strawman:error_stack
 
  Feedback wanted.
 
  You might look at the Mueller format:
  https://gist.github.com/312a55532fac0296f2ab
 
  Note that the V8 stack is not a property of the error object but
  rather a getter. This is a valuable performance advantage since the
  stack is not converted from C++ array to string until the getter is
  called.

 This is well known. Engines can implement lazy data properties too but
 maybe that is too magical. I'm fine speccing this as an accessor but
 if it is an accessor we should spec it as on Error.prototype and not
 on the instance.

  Critical for tools is the ability to linkify the stack trace so we
  need the grammar to allow the URLs to be unambiguously parsable,
  including avoiding content of the error message from interfering.

 Agreed and I believe the V8 format fulfills that requirement.

 --
 erik
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Jason Orendorff]

On Thu, Jun 7, 2012 at 1:37 PM, Erik Arvidsson erik.arvids...@gmail.com wrote:
 I wrote a new strawman for Error stack which is now available in some
 form in all major browser (if betas are considered).

 http://wiki.ecmascript.org/doku.php?id=strawman:error_stack

 Feedback wanted.

This isn't machine parseable in all cases, since the .message may
contain newlines and can end with something like \n  at ...

Changing this in Firefox would affect any Firefox addons that use
Error.stack, but maybe we can take that hit.

-j
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Erik Arvidsson]

On Thu, Jun 7, 2012 at 1:12 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
 This isn't machine parseable in all cases, since the .message may
 contain newlines and can end with something like \n  at ...

That is a good point. This also applies to the name of a function
(and object when included). It is trivial to create a function name
that breaks the V8 style formatting. SpiderMonkey gets away with
this by using the name of the function expression and it does not try
to deduce a name based on the code..

window['\n@'] = function() {
  alert(new Error().stack);
};

When I first set out to write the proposal I was set on the
SpiderMonkey formatting but as I researched this I drifted closer and
closer to the V8 formatting. The thing that convinced me was eval.

I also don't think that providing ErrorName: ErrorMessage is a hard
requirement. The same information is already available using
errorObject.name and errorObject.message.

If we remove the first line and require that non identifiers are
quoted I think we can guarantee that the value is machine parseable
again.

 Changing this in Firefox would affect any Firefox addons that use
 Error.stack, but maybe we can take that hit.

For web apps we already have to parse two different versions so I'm
not too concerned about that case. The WebKit mobile web does not
depend on either format (Safari doesn't have it in any shipping
version yet) so the two problematic big eco systems are Firefox and
Chrome extensions (and Node.js?)

-- 
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Error stack

[Domenic Denicola]

Machine-parsability might be reaching too far, especially if you lose the 
benefits of nice function/method name inference. Instead, perhaps a separate 
strawman to standardize something like the V8 stack trace API [1]?

It is used in Node for providing long stack traces [2], [3], [4]. It's a bit 
cumbersome, e.g. maybe a separate error.stackFrames getter would be nicer and 
the Java-style getFileName() methods could become simple properties. But the 
fact that it exists is extremely useful.

[1]: http://code.google.com/p/v8/wiki/JavaScriptStackTraceApi
[2]: https://github.com/tlrobinson/long-stack-traces
[3]: 
https://github.com/kriskowal/q/blob/0c1ffdc50a6ea77c3e97075fab35ab9f7b2d/q.js#L261-405,
 
https://github.com/kriskowal/q/blob/0c1ffdc50a6ea77c3e97075fab35ab9f7b2d/q.js#L1307-1321
[4]: 
https://github.com/NobleJS/WinningJS-todo/commit/2d4ca10c4f672dac9f021b697c4c72bbff321ed9


From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf 
of Erik Arvidsson [erik.arvids...@gmail.com]
Sent: Thursday, June 07, 2012 16:39
To: Jason Orendorff
Cc: es-discuss@mozilla.org
Subject: Re: Error stack

On Thu, Jun 7, 2012 at 1:12 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
 This isn't machine parseable in all cases, since the .message may
 contain newlines and can end with something like \n  at ...

That is a good point. This also applies to the name of a function
(and object when included). It is trivial to create a function name
that breaks the V8 style formatting. SpiderMonkey gets away with
this by using the name of the function expression and it does not try
to deduce a name based on the code..

window['\n@'] = function() {
  alert(new Error().stack);
};

When I first set out to write the proposal I was set on the
SpiderMonkey formatting but as I researched this I drifted closer and
closer to the V8 formatting. The thing that convinced me was eval.

I also don't think that providing ErrorName: ErrorMessage is a hard
requirement. The same information is already available using
errorObject.name and errorObject.message.

If we remove the first line and require that non identifiers are
quoted I think we can guarantee that the value is machine parseable
again.

 Changing this in Firefox would affect any Firefox addons that use
 Error.stack, but maybe we can take that hit.

For web apps we already have to parse two different versions so I'm
not too concerned about that case. The WebKit mobile web does not
depend on either format (Safari doesn't have it in any shipping
version yet) so the two problematic big eco systems are Firefox and
Chrome extensions (and Node.js?)

--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Charles Kendrick]

Thanks for taking this on Erik.

I would suggest the following, which is mostly based on the
information it was possible to extract from IE6 (which is amazingly
still the leader in programmatic access to error information) as well
as information we were able to get by writing a Firefox extension.

All of the following might be optionally enabled, similar to
Error.stackTraceLimit, if you think it's too verbose.

1. show the parameter values

.. and do so intelligently:

a. Show Arrays with length: Array[5]

b. truncate long strings and show length: the quick brown fox jumped ...[45]

c. format dates compactly: Date(2012/5/2 5:00)

d. for Objects, use the toString() method if it's been customized on
the object, and for other objects instead of [Object object] pick
salient properties such as ID/id, name, title, type, or label.

For example, in our traces we would show Obj{title:foo} if an Object
with no customized toString() were present as a parameter and it
happened to have a title property.

This is a general strategy for dumping the value of something shown in
a stack trace and is assumed for other features below.


2. show the value of this if it's not the window

This is extremely important in OO frameworks.  It tells you exactly
what instances are involved in the call stack.  Traces that go through
recursive algorithms can be almost useless without this.

For example:

ReferenceError: doSomething is not defined
at f (http://www.example.com/temp.html:5:5) [on Obj{ID:foo}]
at g (eval at h (http://www.example.com/temp.html:6:5))
at http://www.example.com/temp.html:11:1


3. optionally show the line of code that crashed

ReferenceError: doSomething is not defined
code: this.doSomething()
at f (http://www.example.com/temp.html:5:5)
at g (eval at h (http://www.example.com/temp.html:6:5))
at http://www.example.com/temp.html:11:1


3. optionally show the line of code that calls down to the next frame

ReferenceError: doSomething is not defined
code: this.doSomething()
at f (http://www.example.com/temp.html:5:5)
code: if (something) f();
at g (eval at h (http://www.example.com/temp.html:6:5))
code: g(currentValue);
at http://www.example.com/temp.html:11:1


4. optionally dump all non-parameter local variables for the crashing frame

ReferenceError: doSomething is not defined
code: this.doSomething()
vars:
value: 5
parent: Obj{name:foo}
at f (http://www.example.com/temp.html:5:5) [on: Obj{ID:1}]
code: if (something) f();



A couple quick notes: some might argue this is pushing stacks to do
things debuggers do.  But, you don't have a debugger when you are
trying to solve a problem in a live application, and you don't have a
debugger when a customer is sending you logs and you can't even access
the application.

But with stack traces like the above, especially when combined with
good logging, you can be almost psychic when analyzing issues.

This information is very easy for the browser implementer to retrieve
so I don't think it imposes an undue burden, and from my 13 years of
experience helping customers with issues in a large JavaScript
framework, I can tell you that the value is difficult to overstate.

On Thu, Jun 7, 2012 at 11:37 AM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
 I wrote a new strawman for Error stack which is now available in some
 form in all major browser (if betas are considered).

 http://wiki.ecmascript.org/doku.php?id=strawman:error_stack

 Feedback wanted.

 --
 erik
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Charles Kendrick]

I agree that something like error.stackFrames would be ideal.  However
I would say the V8 stack trace API is missing 3 key things:

1. access to parameter values
2. access to local variables defined in the function
3. access to the line of code that crashed / called the next frame
without having to go download the source file and use the line number
to find it.  This is even more important for generated / eval()'d code
where there is no source file per se.

Note that access to the function for the frame via getFunction() is
inadequate - doesn't work with recursion.  APIs to get local variables
and parameter values would need to be on the stackFrame.

P.S. fascinating to learn that Node.js does long traces, we have done
the same in SmartClient for a long time.

On Thu, Jun 7, 2012 at 2:47 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
 Machine-parsability might be reaching too far, especially if you lose the 
 benefits of nice function/method name inference. Instead, perhaps a separate 
 strawman to standardize something like the V8 stack trace API [1]?

 It is used in Node for providing long stack traces [2], [3], [4]. It's a bit 
 cumbersome, e.g. maybe a separate error.stackFrames getter would be nicer and 
 the Java-style getFileName() methods could become simple properties. But the 
 fact that it exists is extremely useful.

 [1]: http://code.google.com/p/v8/wiki/JavaScriptStackTraceApi
 [2]: https://github.com/tlrobinson/long-stack-traces
 [3]: 
 https://github.com/kriskowal/q/blob/0c1ffdc50a6ea77c3e97075fab35ab9f7b2d/q.js#L261-405,
  
 https://github.com/kriskowal/q/blob/0c1ffdc50a6ea77c3e97075fab35ab9f7b2d/q.js#L1307-1321
 [4]: 
 https://github.com/NobleJS/WinningJS-todo/commit/2d4ca10c4f672dac9f021b697c4c72bbff321ed9

 
 From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on 
 behalf of Erik Arvidsson [erik.arvids...@gmail.com]
 Sent: Thursday, June 07, 2012 16:39
 To: Jason Orendorff
 Cc: es-discuss@mozilla.org
 Subject: Re: Error stack

 On Thu, Jun 7, 2012 at 1:12 PM, Jason Orendorff
 jason.orendo...@gmail.com wrote:
 This isn't machine parseable in all cases, since the .message may
 contain newlines and can end with something like \n  at ...

 That is a good point. This also applies to the name of a function
 (and object when included). It is trivial to create a function name
 that breaks the V8 style formatting. SpiderMonkey gets away with
 this by using the name of the function expression and it does not try
 to deduce a name based on the code..

 window['\n@'] = function() {
  alert(new Error().stack);
 };

 When I first set out to write the proposal I was set on the
 SpiderMonkey formatting but as I researched this I drifted closer and
 closer to the V8 formatting. The thing that convinced me was eval.

 I also don't think that providing ErrorName: ErrorMessage is a hard
 requirement. The same information is already available using
 errorObject.name and errorObject.message.

 If we remove the first line and require that non identifiers are
 quoted I think we can guarantee that the value is machine parseable
 again.

 Changing this in Firefox would affect any Firefox addons that use
 Error.stack, but maybe we can take that hit.

 For web apps we already have to parse two different versions so I'm
 not too concerned about that case. The WebKit mobile web does not
 depend on either format (Safari doesn't have it in any shipping
 version yet) so the two problematic big eco systems are Firefox and
 Chrome extensions (and Node.js?)

 --
 erik
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[David Herman]

 I wrote a new strawman for Error stack which is now available in some
 form in all major browser (if betas are considered).

Thanks for writing this up. I left a couple comments on the strawman, but I 
should just respond here.

- I'm in favor of trying to come up with a common format as much as possible, 
so that programs that manipulate stack traces can be written once and don't 
have to build compatibility layers like http://stacktracejs.com.

- But we should be careful not to overspecify in ways that constrain 
optimizations. Despite the fact that we usually err on the side of full 
specification, this is actually one place where I think we can and should avoid 
it. The Chrome stackTraceLimit idea is interesting, but does V8 actually 
promise never to inline within the most recent n frames?

- You mentioned that compatibility requires error.stack to be a string, even 
though programs would really like to have a structured version. Should we offer 
a different property with structured stack frame info (probably with a getter 
to allow straight-forward lazy construction), called error.stackFrames or 
error.stackEntries or something?

Thanks,
Dave

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss