Error stack strawman
Terry Stanley
cocoonfx at gmail.com
Thu Feb 11 18:21:54 UTC 2016
[+es-discuss] resending with es-discuss included.
On Tue, Feb 9, 2016 at 9:48 PM, Terry Stanley <cocoonfx at gmail.com> 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 <bzbarsky at mit.edu> 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
>>> <http://wiki.erights.org/wiki/Causeway_Platform_Developer> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160211/d9c19f8a/attachment.html>
More information about the es-discuss
mailing list