Track async causal stack traces

Track async causal stack traces

This CL improves the stack traces that accompany exceptions. Whenever an
async function is entered, we remember how we got there. This is similar
in spirit to package:stack_trace but the implementation is more efficient
and memory usage can be more easily reasoned about.

Tracking causal stack traces:

- [x] Upon entry to an async function, capture the synchronous stack trace prefix and store it into the closure.
- [x] Upon entry to an async* function, capture the synchronous stack trace prefix and store it into the closure.
- [x] Before returning from an async function, clear the Thread's asynchronous stack trace.
- [x] After resuming an async function, load the sychronous stack trace prefix into the Thread.
- [x] Filter stack traces to remove async machinery.

Service protocol changes:

- [x] Send causal async stack trace.

Observatory changes:

- [x] Display causal async stack trace below async functions.

Fixes https://github.com/dart-lang/sdk/issues/27661

R=asiva@google.com, rmacnak@google.com

Comparisons: https://docs.google.com/a/google.com/document/d/10r6jEqr8OCiDZ4y9SYU_uOimcHiOGAZMly2ghTErALI/edit?usp=sharing
Committed: https://github.com/dart-lang/sdk/commit/a0ee5b24db5420d8256f22e89561d13038f3320c

[Cutch, 2017-01-18 23:27:05]

Description was changed from

==========
Track async causal stack traces

This CL improves the stack traces that accompany exceptions. Whenever an
async function is entered, we remember how we got there. This is similar
in spirit to package:stack_trace but the implementation is more efficient
and memory usage can be more easily reasoned about.

Tracking causal stack traces:

- [x] Upon entry to an async function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Upon entry to an async* function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Before returning from an async function, clear the Thread's asynchronous
stack trace.
- [x] After resuming an async function, load the sychronous stack trace prefix
into the Thread.
- [x] Filter stack traces to remove async machinery.

Service protocol changes:

- [ ] Send causal async stack trace.

Observatory changes:

- [ ] Display causal async stack trace below async functions.

BUG=
==========

to

==========
Track async causal stack traces

This CL improves the stack traces that accompany exceptions. Whenever an
async function is entered, we remember how we got there. This is similar
in spirit to package:stack_trace but the implementation is more efficient
and memory usage can be more easily reasoned about.

Tracking causal stack traces:

- [x] Upon entry to an async function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Upon entry to an async* function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Before returning from an async function, clear the Thread's asynchronous
stack trace.
- [x] After resuming an async function, load the sychronous stack trace prefix
into the Thread.
- [x] Filter stack traces to remove async machinery.

Service protocol changes:

- [ ] Send causal async stack trace.

Observatory changes:

- [ ] Display causal async stack trace below async functions.

Fixes https://github.com/dart-lang/sdk/issues/27661
==========

[Cutch, 2017-01-18 23:29:51]

Description was changed from

==========
Track async causal stack traces

This CL improves the stack traces that accompany exceptions. Whenever an
async function is entered, we remember how we got there. This is similar
in spirit to package:stack_trace but the implementation is more efficient
and memory usage can be more easily reasoned about.

Tracking causal stack traces:

- [x] Upon entry to an async function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Upon entry to an async* function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Before returning from an async function, clear the Thread's asynchronous
stack trace.
- [x] After resuming an async function, load the sychronous stack trace prefix
into the Thread.
- [x] Filter stack traces to remove async machinery.

Service protocol changes:

- [ ] Send causal async stack trace.

Observatory changes:

- [ ] Display causal async stack trace below async functions.

Fixes https://github.com/dart-lang/sdk/issues/27661
==========

to

==========
Track async causal stack traces

This CL improves the stack traces that accompany exceptions. Whenever an
async function is entered, we remember how we got there. This is similar
in spirit to package:stack_trace but the implementation is more efficient
and memory usage can be more easily reasoned about.

Tracking causal stack traces:

- [x] Upon entry to an async function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Upon entry to an async* function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Before returning from an async function, clear the Thread's asynchronous
stack trace.
- [x] After resuming an async function, load the sychronous stack trace prefix
into the Thread.
- [x] Filter stack traces to remove async machinery.

Service protocol changes:

- [ ] Send causal async stack trace.

Observatory changes:

- [ ] Display causal async stack trace below async functions.

Before:

Before w/ package:stack_trace:

After:

Fixes https://github.com/dart-lang/sdk/issues/27661
==========

[Cutch, 2017-01-19 18:06:07]

Description was changed from

==========
Track async causal stack traces

This CL improves the stack traces that accompany exceptions. Whenever an
async function is entered, we remember how we got there. This is similar
in spirit to package:stack_trace but the implementation is more efficient
and memory usage can be more easily reasoned about.

Tracking causal stack traces:

- [x] Upon entry to an async function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Upon entry to an async* function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Before returning from an async function, clear the Thread's asynchronous
stack trace.
- [x] After resuming an async function, load the sychronous stack trace prefix
into the Thread.
- [x] Filter stack traces to remove async machinery.

Service protocol changes:

- [ ] Send causal async stack trace.

Observatory changes:

- [ ] Display causal async stack trace below async functions.

Before:

Before w/ package:stack_trace:

After:

Fixes https://github.com/dart-lang/sdk/issues/27661
==========

to

==========
Track async causal stack traces

This CL improves the stack traces that accompany exceptions. Whenever an
async function is entered, we remember how we got there. This is similar
in spirit to package:stack_trace but the implementation is more efficient
and memory usage can be more easily reasoned about.

Tracking causal stack traces:

- [x] Upon entry to an async function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Upon entry to an async* function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Before returning from an async function, clear the Thread's asynchronous
stack trace.
- [x] After resuming an async function, load the sychronous stack trace prefix
into the Thread.
- [x] Filter stack traces to remove async machinery.

Service protocol changes:

- [ ] Send causal async stack trace.

Observatory changes:

- [ ] Display causal async stack trace below async functions.

Fixes https://github.com/dart-lang/sdk/issues/27661

Comparisons:
https://docs.google.com/a/google.com/document/d/10r6jEqr8OCiDZ4y9SYU_uOimcHiO...
==========

[Cutch, 2017-01-19 18:15:03]

johnmccutchan@google.com changed reviewers:
+ asiva@google.com, turnidge@google.com

[Cutch, 2017-01-20 01:56:44]

Description was changed from

==========
Track async causal stack traces

This CL improves the stack traces that accompany exceptions. Whenever an
async function is entered, we remember how we got there. This is similar
in spirit to package:stack_trace but the implementation is more efficient
and memory usage can be more easily reasoned about.

Tracking causal stack traces:

- [x] Upon entry to an async function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Upon entry to an async* function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Before returning from an async function, clear the Thread's asynchronous
stack trace.
- [x] After resuming an async function, load the sychronous stack trace prefix
into the Thread.
- [x] Filter stack traces to remove async machinery.

Service protocol changes:

- [ ] Send causal async stack trace.

Observatory changes:

- [ ] Display causal async stack trace below async functions.

Fixes https://github.com/dart-lang/sdk/issues/27661

Comparisons:
https://docs.google.com/a/google.com/document/d/10r6jEqr8OCiDZ4y9SYU_uOimcHiO...
==========

to

==========
Track async causal stack traces

This CL improves the stack traces that accompany exceptions. Whenever an
async function is entered, we remember how we got there. This is similar
in spirit to package:stack_trace but the implementation is more efficient
and memory usage can be more easily reasoned about.

Tracking causal stack traces:

- [x] Upon entry to an async function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Upon entry to an async* function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Before returning from an async function, clear the Thread's asynchronous
stack trace.
- [x] After resuming an async function, load the sychronous stack trace prefix
into the Thread.
- [x] Filter stack traces to remove async machinery.

Service protocol changes:

- [x] Send causal async stack trace.

Observatory changes:

- [x] Display causal async stack trace below async functions.

Fixes https://github.com/dart-lang/sdk/issues/27661

Comparisons:
https://docs.google.com/a/google.com/document/d/10r6jEqr8OCiDZ4y9SYU_uOimcHiO...
==========

[Cutch, 2017-01-20 02:17:44]

PTAL

[Cutch, 2017-01-25 22:57:22]

On 2017/01/20 02:17:44, Cutch wrote:
> PTAL

*ping*

[Cutch, 2017-01-25 22:57:31]

johnmccutchan@google.com changed reviewers:
+ rmacnak@google.com

[Cutch, 2017-01-25 22:57:37]

+rmacnak

[rmacnak, 2017-01-26 18:05:58]

Some initial comments

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/async_patch...
File runtime/lib/async_patch.dart (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/async_patch...
runtime/lib/async_patch.dart:198: Object _asyncStackTraceHelper() native
"StackTrace_forAsyncMethod";
StackTrace _asyncStackTraceHelper()

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace.cc
File runtime/lib/stacktrace.cc (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace....
runtime/lib/stacktrace.cc:24: static RawStackTrace*
CurrentSyncStackTrace(Thread* thread, Isolate* isolate) {
isolate parameter not used

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace....
runtime/lib/stacktrace.cc:48: Isolate* isolate,
isolate parameter not used

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace....
runtime/lib/stacktrace.cc:57: Code& code = Code::Handle();
Handle(zone)

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace....
runtime/lib/stacktrace.cc:125: code = Code::RawCast(async_code_array.At(i));
code ^= async_code_array.At(i)

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace....
runtime/lib/stacktrace.cc:126: offset =
Smi::RawCast(async_pc_offset_array.At(i));
offset ^=

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace.h
File runtime/lib/stacktrace.h (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace....
runtime/lib/stacktrace.h:18: const StackTrace& GetCurrentStackTrace(int
skip_frames);
This function shouldn't return a handle...

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/debugger.cc
File runtime/vm/debugger.cc (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/debugger.cc#...
runtime/vm/debugger.cc:260: function_(Function::ZoneHandle(code.function())),
Doesn't mutate, replace slot with an function.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/debugger.cc#...
runtime/vm/debugger.cc:3287: // will report only one as reached. ; then  ; then
an general breakpoint.
Copy-paste error in comment.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/exceptions.cc
File runtime/vm/exceptions.cc (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/exceptions.c...
runtime/vm/exceptions.cc:375: return GetStackTraceForException();
Inline and remove?

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/flag_list.h
File runtime/vm/flag_list.h (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/flag_list.h#...
runtime/vm/flag_list.h:134: R(sane_async_stacks, false, bool, true, "Improved
async stacks")             \
causal_async_stacks?

Flutter should probably turn this off in their profile mode as well.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/flow_graph_b...
File runtime/vm/flow_graph_builder.cc (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/flow_graph_b...
runtime/vm/flow_graph_builder.cc:1134: if (function.IsAsyncClosure() ||
function.IsAsyncGenClosure()) {
&& FLAG_sane_async_stacks

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/flow_graph_b...
runtime/vm/flow_graph_builder.cc:1144: Resolver::ResolveStatic(async_lib,
String::ZoneHandle(String::null()),
It might be worth caching the three helper functions in
ObjectStore::InitKnownObjects.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/flow_graph_b...
runtime/vm/flow_graph_builder.cc:1148:
async_clear_thread_stack_trace.set_is_debuggable(false);
I thought we can't step into native functions anyway.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/flow_graph_b...
runtime/vm/flow_graph_builder.cc:3815: (function.IsAsyncClosure() ||
function.IsAsyncGenClosure())) {
&& FLAG_sane_async_stacks

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/intrinsifier...
File runtime/vm/intrinsifier_x64.cc (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/intrinsifier...
runtime/vm/intrinsifier_x64.cc:2283: void
Intrinsifier::ClearAsyncThreadStackTrace(Assembler* assembler) {
Plus the other architectures.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/object.cc
File runtime/vm/object.cc (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/object.cc#ne...
runtime/vm/object.cc:22634: Function& function = Function::Handle();
Handle(zone)

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/object.cc#ne...
runtime/vm/object.cc:22644: const char* kAsynchronousGap = "<asynchronous
suspension>\n";
No need to dup the string.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/object.cc#ne...
runtime/vm/object.cc:22658: OS::SNPrint(chars, truncated_len, "%s", kTruncated);
No need to dup the string.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/parser.cc
File runtime/vm/parser.cc (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/parser.cc#ne...
runtime/vm/parser.cc:3471: // In order to produce sane asynchronous stacks we
rely on this function
To collect them efficiently.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/parser.cc#ne...
runtime/vm/parser.cc:7053: // Add to AST:
if (FLAG_sane_async_stacks)

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/parser.cc#ne...
runtime/vm/parser.cc:7268: // Add to AST:
if (FLAG_sane_async_stacks)

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/thread.h
File runtime/vm/thread.h (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/thread.h#new...
runtime/vm/thread.h:739: RawStackTrace* async_stack_trace_;
Move up to the "Accessed from generated code" block. We need to keep fields used
from generated code above any members that aren't word-sized to make offsets
match across architectures to support cross-compiling AOT.

[siva, 2017-01-26 19:26:23]

We should append to the comment in thread_registry.h
that the async stack trace mechanism is another case
where we expect the mutator thread to be scheduled back
on the same thread (see big comment in that header file).

Are you going to be doing other targets in the same CL
or a different CL?

Is a simple test case possible?

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/async_patch...
File runtime/lib/async_patch.dart (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/async_patch...
runtime/lib/async_patch.dart:195: /// Returns a
typo

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace.cc
File runtime/lib/stacktrace.cc (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace....
runtime/lib/stacktrace.cc:24: static RawStackTrace*
CurrentSyncStackTrace(Thread* thread, Isolate* isolate) {
Thread is available here, you could extract the zone and use it for all the
handle creations here and in other functions in this file.

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace....
runtime/lib/stacktrace.cc:26: const intptr_t skip_frames = 1;
maybe document which frame is skipped

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace....
runtime/lib/stacktrace.cc:42: return StackTrace::New(code_array,
pc_offset_array);
Do you think there stack traces are going to be living for a while (i.e will
survive new gen GCs) could consider allocating in old space if so.

Not sure about it though.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/flow_graph_b...
File runtime/vm/flow_graph_builder.cc (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/flow_graph_b...
runtime/vm/flow_graph_builder.cc:3839: private_name, 1, Object::null_array()));
Agree with Ryan might be worth caching these functions.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/intrinsifier...
File runtime/vm/intrinsifier_x64.cc (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/intrinsifier...
runtime/vm/intrinsifier_x64.cc:2292: __ LoadObject(RAX, Object::null_object());
why is RAX being cleared here with the null object

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/stack_trace.cc
File runtime/vm/stack_trace.cc (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/stack_trace....
runtime/vm/stack_trace.cc:1: // Copyright (c) 2015, the Dart project authors. 
Please see the AUTHORS file
2017

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/stack_trace....
runtime/vm/stack_trace.cc:34: break;
can this be a return here, that is
return frame_count;

Would avoid that extra ASSERT check at the bottom then, it could just
be ASSERT(async_function_is_null);

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/stack_trace....
runtime/vm/stack_trace.cc:58: Smi& offset = Smi::Handle();
I am assuming these functions are going to be called a lot and would make sense
to use the Zone parameter for all the handles created in this file.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/stack_trace....
runtime/vm/stack_trace.cc:73: count--;
Why decrement an input parameter 'count' here, why not just
switch the while condition to
while ((frame != NULL) && (collected_frames_count < count)) {

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/stack_trace.h
File runtime/vm/stack_trace.h (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/stack_trace....
runtime/vm/stack_trace.h:1: // Copyright (c) 2016, the Dart project authors. 
Please see the AUTHORS file
2017

[siva, 2017-01-27 00:58:24]

As discussed offline, we could consider chaining the stack trace objects instead
of concatenating them. maybe not for this CL but as a future optimization.

[Cutch, 2017-01-31 23:45:31]

Thanks for the reviews.

I've done most of the request changes. The following is TODO (so don't review
this CL again just yet):

- [ ] unit tests
- [ ] chain stacks together instead of concatenating
- [ ] other architectures
- [ ] Add pre-defined environment variable
('dart.developer.causal_async_stacks')

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/async_patch...
File runtime/lib/async_patch.dart (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/async_patch...
runtime/lib/async_patch.dart:195: /// Returns a
On 2017/01/26 19:26:22, siva wrote:
> typo

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/async_patch...
runtime/lib/async_patch.dart:198: Object _asyncStackTraceHelper() native
"StackTrace_forAsyncMethod";
On 2017/01/26 18:05:57, rmacnak wrote:
> StackTrace _asyncStackTraceHelper() 

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace.cc
File runtime/lib/stacktrace.cc (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace....
runtime/lib/stacktrace.cc:24: static RawStackTrace*
CurrentSyncStackTrace(Thread* thread, Isolate* isolate) {
On 2017/01/26 18:05:57, rmacnak wrote:
> isolate parameter not used

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace....
runtime/lib/stacktrace.cc:24: static RawStackTrace*
CurrentSyncStackTrace(Thread* thread, Isolate* isolate) {
On 2017/01/26 19:26:23, siva wrote:
> Thread is available here, you could extract the zone and use it for all the
> handle creations here and in other functions in this file.

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace....
runtime/lib/stacktrace.cc:26: const intptr_t skip_frames = 1;
On 2017/01/26 19:26:22, siva wrote:
> maybe document which frame is skipped

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace....
runtime/lib/stacktrace.cc:42: return StackTrace::New(code_array,
pc_offset_array);
On 2017/01/26 19:26:23, siva wrote:
> Do you think there stack traces are going to be living for a while (i.e will
> survive new gen GCs) could consider allocating in old space if so.
> 
> Not sure about it though.

Acknowledged.

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace....
runtime/lib/stacktrace.cc:48: Isolate* isolate,
On 2017/01/26 18:05:57, rmacnak wrote:
> isolate parameter not used

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace....
runtime/lib/stacktrace.cc:57: Code& code = Code::Handle();
On 2017/01/26 18:05:57, rmacnak wrote:
> Handle(zone)

Done (here and elsewhere).

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace....
runtime/lib/stacktrace.cc:125: code = Code::RawCast(async_code_array.At(i));
On 2017/01/26 18:05:57, rmacnak wrote:
> code ^= async_code_array.At(i)

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace....
runtime/lib/stacktrace.cc:126: offset =
Smi::RawCast(async_pc_offset_array.At(i));
On 2017/01/26 18:05:57, rmacnak wrote:
> offset ^=

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace.h
File runtime/lib/stacktrace.h (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/lib/stacktrace....
runtime/lib/stacktrace.h:18: const StackTrace& GetCurrentStackTrace(int
skip_frames);
On 2017/01/26 18:05:57, rmacnak wrote:
> This function shouldn't return a handle...

This is old code. Acknowledged.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/debugger.cc
File runtime/vm/debugger.cc (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/debugger.cc#...
runtime/vm/debugger.cc:260: function_(Function::ZoneHandle(code.function())),
On 2017/01/26 18:05:57, rmacnak wrote:
> Doesn't mutate, replace slot with an function.

Not entirely sure I understand your comment here.

But, if it is in reference to changing from a const Function& to a Function&,
this isn't used in this CL but a follow on CL will use it.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/debugger.cc#...
runtime/vm/debugger.cc:3287: // will report only one as reached. ; then  ; then
an general breakpoint.
On 2017/01/26 18:05:57, rmacnak wrote:
> Copy-paste error in comment.

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/exceptions.cc
File runtime/vm/exceptions.cc (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/exceptions.c...
runtime/vm/exceptions.cc:375: return GetStackTraceForException();
On 2017/01/26 18:05:57, rmacnak wrote:
> Inline and remove?

Acknowledged.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/flag_list.h
File runtime/vm/flag_list.h (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/flag_list.h#...
runtime/vm/flag_list.h:134: R(sane_async_stacks, false, bool, true, "Improved
async stacks")             \
On 2017/01/26 18:05:57, rmacnak wrote:
> causal_async_stacks?
> 

Done.

> Flutter should probably turn this off in their profile mode as well.

ACK.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/flow_graph_b...
File runtime/vm/flow_graph_builder.cc (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/flow_graph_b...
runtime/vm/flow_graph_builder.cc:1134: if (function.IsAsyncClosure() ||
function.IsAsyncGenClosure()) {
On 2017/01/26 18:05:57, rmacnak wrote:
> && FLAG_sane_async_stacks

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/flow_graph_b...
runtime/vm/flow_graph_builder.cc:1144: Resolver::ResolveStatic(async_lib,
String::ZoneHandle(String::null()),
On 2017/01/26 18:05:57, rmacnak wrote:
> It might be worth caching the three helper functions in
> ObjectStore::InitKnownObjects.

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/flow_graph_b...
runtime/vm/flow_graph_builder.cc:1148:
async_clear_thread_stack_trace.set_is_debuggable(false);
On 2017/01/26 18:05:57, rmacnak wrote:
> I thought we can't step into native functions anyway.

Acknowledged.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/flow_graph_b...
runtime/vm/flow_graph_builder.cc:3815: (function.IsAsyncClosure() ||
function.IsAsyncGenClosure())) {
On 2017/01/26 18:05:57, rmacnak wrote:
> && FLAG_sane_async_stacks

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/flow_graph_b...
runtime/vm/flow_graph_builder.cc:3839: private_name, 1, Object::null_array()));
On 2017/01/26 19:26:23, siva wrote:
> Agree with Ryan might be worth caching these functions.

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/intrinsifier...
File runtime/vm/intrinsifier_x64.cc (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/intrinsifier...
runtime/vm/intrinsifier_x64.cc:2292: __ LoadObject(RAX, Object::null_object());
On 2017/01/26 19:26:23, siva wrote:
> why is RAX being cleared here with the null object

RAX is being cleared so that we return "null" from the function.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/object.cc
File runtime/vm/object.cc (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/object.cc#ne...
runtime/vm/object.cc:22634: Function& function = Function::Handle();
On 2017/01/26 18:05:58, rmacnak wrote:
> Handle(zone)

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/object.cc#ne...
runtime/vm/object.cc:22644: const char* kAsynchronousGap = "<asynchronous
suspension>\n";
On 2017/01/26 18:05:58, rmacnak wrote:
> No need to dup the string.

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/object.cc#ne...
runtime/vm/object.cc:22658: OS::SNPrint(chars, truncated_len, "%s", kTruncated);
On 2017/01/26 18:05:58, rmacnak wrote:
> No need to dup the string.

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/parser.cc
File runtime/vm/parser.cc (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/parser.cc#ne...
runtime/vm/parser.cc:3471: // In order to produce sane asynchronous stacks we
rely on this function
On 2017/01/26 18:05:58, rmacnak wrote:
> To collect them efficiently.

Done (here and elsewhere).

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/parser.cc#ne...
runtime/vm/parser.cc:7268: // Add to AST:
On 2017/01/26 18:05:58, rmacnak wrote:
> if (FLAG_sane_async_stacks)

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/stack_trace.cc
File runtime/vm/stack_trace.cc (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/stack_trace....
runtime/vm/stack_trace.cc:1: // Copyright (c) 2015, the Dart project authors. 
Please see the AUTHORS file
On 2017/01/26 19:26:23, siva wrote:
> 2017

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/stack_trace....
runtime/vm/stack_trace.cc:34: break;
On 2017/01/26 19:26:23, siva wrote:
> can this be a return here, that is
> return frame_count;
> 
> Would avoid that extra ASSERT check at the bottom then, it could just
> be ASSERT(async_function_is_null);

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/stack_trace....
runtime/vm/stack_trace.cc:58: Smi& offset = Smi::Handle();
On 2017/01/26 19:26:23, siva wrote:
> I am assuming these functions are going to be called a lot and would make
sense
> to use the Zone parameter for all the handles created in this file.

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/stack_trace....
runtime/vm/stack_trace.cc:73: count--;
On 2017/01/26 19:26:23, siva wrote:
> Why decrement an input parameter 'count' here, why not just
> switch the while condition to
> while ((frame != NULL) && (collected_frames_count < count)) {

Done.

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/thread.h
File runtime/vm/thread.h (right):

https://codereview.chromium.org/2646443005/diff/40001/runtime/vm/thread.h#new...
runtime/vm/thread.h:739: RawStackTrace* async_stack_trace_;
On 2017/01/26 18:05:58, rmacnak wrote:
> Move up to the "Accessed from generated code" block. We need to keep fields
used
> from generated code above any members that aren't word-sized to make offsets
> match across architectures to support cross-compiling AOT.

Done.

[Cutch, 2017-02-01 23:26:05]

I've added unit tests and the predefined Dart environment variable.

Now would be a good time to review again.

What is left:

- [ ] Switch from copying stack traces to chain them.
- [ ] Port to other architectures.

[Cutch, 2017-02-08 00:59:55]

This is ready for final review.

PTAL.

[rmacnak, 2017-02-08 18:34:19]

lgtm w/test

Also add a non-service test like vm/inline_stack_frame_test so we have test
coverage on AOT.

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/li...
File runtime/observatory/lib/src/elements/debugger.dart (right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/li...
runtime/observatory/lib/src/elements/debugger.dart:607: 'sane-async-stacks': [
"causal" to match the vm flag

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/li...
File runtime/observatory/lib/src/repositories/target.dart (right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/li...
runtime/observatory/lib/src/repositories/target.dart:104: if (!identical(1,
1.0)) {
// Dartium

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/debugger.cc
File runtime/vm/debugger.cc (right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/debugger.cc...
runtime/vm/debugger.cc:1621: if (code->is_optimized() &&
!FLAG_precompiled_runtime) {
TODO(rmacnak): Use CodeSourceMap

[siva, 2017-02-08 18:46:29]

LGTM

https://codereview.chromium.org/2646443005/diff/100001/runtime/lib/stacktrace.cc
File runtime/lib/stacktrace.cc (right):

https://codereview.chromium.org/2646443005/diff/100001/runtime/lib/stacktrace...
runtime/lib/stacktrace.cc:21: "Maximum number of asynchronous stack traces
frames remembered in "
asynchronous stack trace frames

https://codereview.chromium.org/2646443005/diff/100001/runtime/lib/stacktrace...
runtime/lib/stacktrace.cc:89: : FLAG_max_async_stack_trace_frames;
Do you think there will still be a need for truncating stack traces if you are
going to be chaining stack traces?

https://codereview.chromium.org/2646443005/diff/140001/runtime/lib/stacktrace.cc
File runtime/lib/stacktrace.cc (right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/lib/stacktrace...
runtime/lib/stacktrace.cc:22: "an asynchronous function activation");
These flags don't seem to be used anymore, can they be removed?

https://codereview.chromium.org/2646443005/diff/140001/runtime/lib/stacktrace...
runtime/lib/stacktrace.cc:32: StackTraceUtils::CountFrames(skip_frames,
null_function);
Pass thread into this function too?

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/te...
File runtime/observatory/tests/service/causal_async_stack_contents_test.dart
(right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/te...
runtime/observatory/tests/service/causal_async_stack_contents_test.dart:12: 
Can you add a comment that these constants need to be adjusted if any code
in the test below is changed.

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/te...
runtime/observatory/tests/service/causal_async_stack_contents_test.dart:52:
expect(asyncStack[2].toString(), contains('helper'));
expect(asyncStack[3].toString(), contains('testMain')); here?

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/te...
runtime/observatory/tests/service/causal_async_stack_contents_test.dart:67:
expect(asyncStack[3].toString(), contains('helper'));
expect(asyncStack[3].toString(), contains('testMain')); here?

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/te...
File runtime/observatory/tests/service/causal_async_stack_presence_test.dart
(right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/te...
runtime/observatory/tests/service/causal_async_stack_presence_test.dart:11: 
Ditto comment here.

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/te...
File
runtime/observatory/tests/service/causal_async_star_stack_contents_test.dart
(right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/te...
runtime/observatory/tests/service/causal_async_star_stack_contents_test.dart:12:

Ditto comment here.

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/te...
runtime/observatory/tests/service/causal_async_star_stack_contents_test.dart:46:
expect(asyncStack[2].toString(), contains('helper'));
expect(asyncStack[3].toString(), contains('testMain')); here?

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/te...
File
runtime/observatory/tests/service/causal_async_star_stack_presence_test.dart
(right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/te...
runtime/observatory/tests/service/causal_async_star_stack_presence_test.dart:11:

ditto comment.

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/intrinsifie...
File runtime/vm/intrinsifier_x64.cc (right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/intrinsifie...
runtime/vm/intrinsifier_x64.cc:2292: __ LoadObject(RAX, Object::null_object());
why does RAX need to be reset to the null object?

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/object.cc
File runtime/vm/object.cc (right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/object.cc#n...
runtime/vm/object.cc:22418: if (code.raw() ==
StubCode::AsynchronousGapMarker_entry()->code()) {
In this case is function.IsNull() true? in that case couldn't this be moved down
to the else case?

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/object_stor...
File runtime/vm/object_store.cc (right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/object_stor...
runtime/vm/object_store.cc:242: 
You could also set up generic string and function handles and reuse them in the
two cases:

String& function_name = ...
Function& function = ...
function_name = async_lib.PrivateName....
function = Resolver::ResolveStatic.....

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/object_stor...
runtime/vm/object_store.cc:248: async_lib, String::ZoneHandle(String::null()),
Object::null_string(),

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/object_stor...
runtime/vm/object_store.cc:256: Resolver::ResolveStatic(async_lib,
String::ZoneHandle(String::null()),
Object::null_string(),

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/stack_trace.cc
File runtime/vm/stack_trace.cc (right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/stack_trace...
runtime/vm/stack_trace.cc:11: intptr_t StackTraceUtils::CountFrames(int
skip_frames,
Thread* thread, int skip_frames,

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/stack_trace.h
File runtime/vm/stack_trace.h (right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/stack_trace...
runtime/vm/stack_trace.h:22: static intptr_t CountFrames(
Thread* thread,

[rmacnak, 2017-02-08 18:52:50]

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/intrinsifie...
File runtime/vm/intrinsifier_x64.cc (right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/intrinsifie...
runtime/vm/intrinsifier_x64.cc:2292: __ LoadObject(RAX, Object::null_object());
On 2017/02/08 18:46:29, siva wrote:
> why does RAX need to be reset to the null object?

The corresponding native function returns null. Intrinsics should always match
the behavior of the regular path.

[siva, 2017-02-08 18:59:12]

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/intrinsifie...
File runtime/vm/intrinsifier_x64.cc (right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/intrinsifie...
runtime/vm/intrinsifier_x64.cc:2292: __ LoadObject(RAX, Object::null_object());
On 2017/02/08 18:52:49, rmacnak wrote:
> On 2017/02/08 18:46:29, siva wrote:
> > why does RAX need to be reset to the null object?
> 
> The corresponding native function returns null. Intrinsics should always match
> the behavior of the regular path.

True, why does the native function return null could be some random object
right?

[Cutch, 2017-02-09 22:24:04]

On 2017/02/08 18:59:12, siva wrote:
>
https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/intrinsifie...
> File runtime/vm/intrinsifier_x64.cc (right):
> 
>
https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/intrinsifie...
> runtime/vm/intrinsifier_x64.cc:2292: __ LoadObject(RAX,
Object::null_object());
> On 2017/02/08 18:52:49, rmacnak wrote:
> > On 2017/02/08 18:46:29, siva wrote:
> > > why does RAX need to be reset to the null object?
> > 
> > The corresponding native function returns null. Intrinsics should always
match
> > the behavior of the regular path.
> 
> True, why does the native function return null could be some random object
> right?

The Dart function is a void function. void Dart functions return null. The
native implementation returns null. The intrinsic returns null by setting RAX.

[Cutch, 2017-02-09 22:45:51]

https://codereview.chromium.org/2646443005/diff/100001/runtime/lib/stacktrace.cc
File runtime/lib/stacktrace.cc (right):

https://codereview.chromium.org/2646443005/diff/100001/runtime/lib/stacktrace...
runtime/lib/stacktrace.cc:21: "Maximum number of asynchronous stack traces
frames remembered in "
On 2017/02/08 18:46:28, siva wrote:
> asynchronous stack trace frames

Removed.

https://codereview.chromium.org/2646443005/diff/100001/runtime/lib/stacktrace...
runtime/lib/stacktrace.cc:89: : FLAG_max_async_stack_trace_frames;
On 2017/02/08 18:46:28, siva wrote:
> Do you think there will still be a need for truncating stack traces if you are
> going to be chaining stack traces?

Removed.

https://codereview.chromium.org/2646443005/diff/140001/runtime/lib/stacktrace.cc
File runtime/lib/stacktrace.cc (right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/lib/stacktrace...
runtime/lib/stacktrace.cc:22: "an asynchronous function activation");
On 2017/02/08 18:46:28, siva wrote:
> These flags don't seem to be used anymore, can they be removed?

Removed.

https://codereview.chromium.org/2646443005/diff/140001/runtime/lib/stacktrace...
runtime/lib/stacktrace.cc:32: StackTraceUtils::CountFrames(skip_frames,
null_function);
On 2017/02/08 18:46:28, siva wrote:
> Pass thread into this function too?

Done.

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/li...
File runtime/observatory/lib/src/elements/debugger.dart (right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/li...
runtime/observatory/lib/src/elements/debugger.dart:607: 'sane-async-stacks': [
On 2017/02/08 18:34:18, rmacnak wrote:
> "causal" to match the vm flag

Done.

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/li...
File runtime/observatory/lib/src/repositories/target.dart (right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/li...
runtime/observatory/lib/src/repositories/target.dart:104: if (!identical(1,
1.0)) {
On 2017/02/08 18:34:18, rmacnak wrote:
> // Dartium

Done.

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/te...
File runtime/observatory/tests/service/causal_async_stack_contents_test.dart
(right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/te...
runtime/observatory/tests/service/causal_async_stack_contents_test.dart:12: 
On 2017/02/08 18:46:28, siva wrote:
> Can you add a comment that these constants need to be adjusted if any code
> in the test below is changed.

Acknowledged.

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/te...
File
runtime/observatory/tests/service/causal_async_star_stack_contents_test.dart
(right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/observatory/te...
runtime/observatory/tests/service/causal_async_star_stack_contents_test.dart:46:
expect(asyncStack[2].toString(), contains('helper'));
On 2017/02/08 18:46:29, siva wrote:
> expect(asyncStack[3].toString(), contains('testMain')); here?

Done.

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/debugger.cc
File runtime/vm/debugger.cc (right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/debugger.cc...
runtime/vm/debugger.cc:1621: if (code->is_optimized() &&
!FLAG_precompiled_runtime) {
On 2017/02/08 18:34:18, rmacnak wrote:
> TODO(rmacnak): Use CodeSourceMap

Done.

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/object.cc
File runtime/vm/object.cc (right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/object.cc#n...
runtime/vm/object.cc:22418: if (code.raw() ==
StubCode::AsynchronousGapMarker_entry()->code()) {
On 2017/02/08 18:46:29, siva wrote:
> In this case is function.IsNull() true? in that case couldn't this be moved
down
> to the else case?

This code has been refactored.

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/object_stor...
File runtime/vm/object_store.cc (right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/object_stor...
runtime/vm/object_store.cc:242: 
On 2017/02/08 18:46:29, siva wrote:
> You could also set up generic string and function handles and reuse them in
the
> two cases:
> 
> String& function_name = ...
> Function& function = ...
> function_name = async_lib.PrivateName....
> function = Resolver::ResolveStatic.....

Done.

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/object_stor...
runtime/vm/object_store.cc:248: async_lib, String::ZoneHandle(String::null()),
On 2017/02/08 18:46:29, siva wrote:
> Object::null_string(),

Done.

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/object_stor...
runtime/vm/object_store.cc:256: Resolver::ResolveStatic(async_lib,
String::ZoneHandle(String::null()),
On 2017/02/08 18:46:29, siva wrote:
> Object::null_string(),

Done.

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/stack_trace.cc
File runtime/vm/stack_trace.cc (right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/stack_trace...
runtime/vm/stack_trace.cc:11: intptr_t StackTraceUtils::CountFrames(int
skip_frames,
On 2017/02/08 18:46:29, siva wrote:
> Thread* thread, int skip_frames,

Done.

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/stack_trace.h
File runtime/vm/stack_trace.h (right):

https://codereview.chromium.org/2646443005/diff/140001/runtime/vm/stack_trace...
runtime/vm/stack_trace.h:22: static intptr_t CountFrames(
On 2017/02/08 18:46:29, siva wrote:
> Thread* thread,

Done.

[Cutch, 2017-02-09 22:46:34]

On 2017/02/08 18:34:19, rmacnak wrote:
> lgtm w/test
> 

Test added tests/language/vm/causal_async_exception_stack_test.dart

[Cutch, 2017-02-09 23:39:52]

Description was changed from

==========
Track async causal stack traces

This CL improves the stack traces that accompany exceptions. Whenever an
async function is entered, we remember how we got there. This is similar
in spirit to package:stack_trace but the implementation is more efficient
and memory usage can be more easily reasoned about.

Tracking causal stack traces:

- [x] Upon entry to an async function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Upon entry to an async* function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Before returning from an async function, clear the Thread's asynchronous
stack trace.
- [x] After resuming an async function, load the sychronous stack trace prefix
into the Thread.
- [x] Filter stack traces to remove async machinery.

Service protocol changes:

- [x] Send causal async stack trace.

Observatory changes:

- [x] Display causal async stack trace below async functions.

Fixes https://github.com/dart-lang/sdk/issues/27661

Comparisons:
https://docs.google.com/a/google.com/document/d/10r6jEqr8OCiDZ4y9SYU_uOimcHiO...
==========

to

==========
Track async causal stack traces

This CL improves the stack traces that accompany exceptions. Whenever an
async function is entered, we remember how we got there. This is similar
in spirit to package:stack_trace but the implementation is more efficient
and memory usage can be more easily reasoned about.

Tracking causal stack traces:

- [x] Upon entry to an async function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Upon entry to an async* function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Before returning from an async function, clear the Thread's asynchronous
stack trace.
- [x] After resuming an async function, load the sychronous stack trace prefix
into the Thread.
- [x] Filter stack traces to remove async machinery.

Service protocol changes:

- [x] Send causal async stack trace.

Observatory changes:

- [x] Display causal async stack trace below async functions.

Fixes https://github.com/dart-lang/sdk/issues/27661

R=asiva@google.com, rmacnak@google.com

Comparisons:
https://docs.google.com/a/google.com/document/d/10r6jEqr8OCiDZ4y9SYU_uOimcHiO...
Committed:
https://github.com/dart-lang/sdk/commit/a0ee5b24db5420d8256f22e89561d13038f3320c
==========

[Cutch, 2017-02-09 23:39:54]

Committed patchset #11 (id:200001) manually as
a0ee5b24db5420d8256f22e89561d13038f3320c.