Error stack strawman

Mark S. Miller erights at google.com
Fri Feb 26 04:19:32 UTC 2016


On Thu, Feb 25, 2016 at 6:45 PM, Gary Guo <nbdd0121 at hotmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160225/6138a848/attachment.html>


More information about the es-discuss mailing list