1. Look for functions/closures only in the script where the breakpoint
is being set.
2. If an inner most closure is found, return that as the best fit.
3. When going over a class' functions, return immediately when a fit is
found as going over the other class functions will not yield a narrower
fit.
BUG=
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2898153006 .
The assertions which tried to assert that we only use
StackFrameIterator to walk frames of the current thread was incorrect.
We already have cases where other threads will walk the stack of the
mutator thread, see below for an example where this can happen.
Thread::VisitObjectPointers was incorrectly passing Thread::Current() to
the StackFrameIterator instead of 'this'. (Code in thread_registry.cc will
loop over a number of threads and calls VisitObjectPointers on them)
Mutator thread:
0 pthread_cond_wait@@GLIBC_2.3.2
1 dart::Monitor::WaitMicros
2 dart::Monitor::Wait
3 dart::MonitorLocker::Wait
4 dart::ThreadBarrier::Sync
5 dart::GCMarker::MarkObjects
6 dart::PageSpace::MarkSweep
7 dart::Heap::CollectOldSpaceGarbage
8 dart::Heap::CollectNewSpaceGarbage
9 dart::Heap::CollectGarbage
10 dart::DN_HelperObject_<native>
11 dart::BootstrapNatives::<native>
<dart frames>
MarkTask thread:
1 dart::EntryFrame::VisitObjectPointers
2 dart::Thread::VisitObjectPointers <---- Walks mutator thread stack
3 dart::ThreadRegistry::VisitObjectPointers <---- Iterates over a number of threads
4 dart::Isolate::VisitStackPointers
5 dart::Isolate::VisitObjectPointers
6 dart::GCMarker::IterateRoots
7 dart::MarkTask::Run
8 dart::ThreadPool::Worker::Loop
9 dart::ThreadPool::Worker::Main
10 dart::ThreadStart
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2845053003 .
- [x] Produce an awaiter stack trace even when there is no awaiter.
- [x] Fix fetching the saved context from Closure.call (fixes --trace_debugger_stacktrace)
Fixes#29200
Example code:
```
main(List<String> args) async {
var f = new Foo();
print(f.a.length);
print('Should not get here');
}
class Foo {
String a;
}
```
BUG=
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2815863002 .
With generic methods, uninstantiated types will require 2 instantiators, one
reflecting the class type arguments (as of today) and one reflecting the
function type arguments (new).
This is work in progress and the second instantiator is always null for now.
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2799373002 .
Related to #29145.
Fixes#29199.
1. Missing source positions in async and async* functions (synthetic code)
2. Added unit tests for issues #28980 and added asyns stack trace testing flags to existing test.
3. Handle uninitialized Completer object when collecting async stack traces.
Still missing is the correct calculation of context levels in ActivationFrame::ContextLevel. This is planned for a separate CL.
R=johnmccutchan@google.com
Review-Url: https://codereview.chromium.org/2786503003 .
- [x] Include the (non-empty) awaiter stack trace in every `getStack` RPC.
- [x] Append the causal stack trace to the final frame of the awaiter stack trace.
- [x] Unit test for awaiter stack trace.
BUG=
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2782703002 .
AssertAssignableInstr::Canonicalize was too restrictive: it can instantiate the
type even if the instantiator is null.
Do not allocate empty TypeArguments handles, but use the common one instead.
R=fschneider@google.com
Review-Url: https://codereview.chromium.org/2759393005 .
Fixes crashes when running reload stress tests with the async stack trace stress flag
(python tools/test.py --hot-reload -t240 --builder-tag no_ipv6 language/await_exceptions_test)
R=johnmccutchan@google.com
Also: Use iterators to get function of a stack frame (refactoring only).
Review-Url: https://codereview.chromium.org/2761143004 .
CL https://codereview.chromium.org/2626753002 introduced a “real” token
position for the synthetic code that re-throws an exception returned
by an await’ed expression. This interferes with setting a breakpoint
in a line that contains an await, since the synthetic code happens to
be at the lowest compiled code address and will thus be picked as the
breakpoint location.
This CL makes the re-throw a synthetic token position again, but
includes synthetic token positions in stack traces. This is an alternative
fix for bug #28325.
BUG=#28770
R=fschneider@google.com
Review-Url: https://codereview.chromium.org/2727803002 .
Original CL: https://codereview.chromium.org/2692803006/
Original commit message:
Tracking the awaiter return call stack:
- [x] Each async function closure now knows who is awaiting on their
return. This is effectively the asynchronous equivalent of the 'frame pointer'.
- [x] Each async* function closure now knows how is listening on their
stream. This is effectively the asynchronous equivalent of the 'frame pointer'.
Detecting uncaught exceptions in async functions:
- [x] Code object keeps a map from :await_jump_var to token position
- [x] Exception Handlers keep track if they are generated (as part of compilation) or directly from user code
- [x] Debugger maps :await_jump_var to a specific try index
R=johnmccutchan@google.com
Review-Url: https://codereview.chromium.org/2725623003 .
Tracking the awaiter return call stack:
- [x] Each async function closure now knows who is awaiting on their
return. This is effectively the asynchronous equivalent of the 'frame pointer'.
- [x] Each async* function closure now knows how is listening on their
stream. This is effectively the asynchronous equivalent of the 'frame pointer'.
Detecting uncaught exceptions in async functions:
- [x] Code object keeps a map from :await_jump_var to token position
- [x] Exception Handlers keep track if they are generated (as part of compilation) or directly from user code
- [x] Debugger maps :await_jump_var to a specific try index
Fixes#27242R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2692803006 .
There was an off by one error when generating the causal async stack trace
in the debugger. We were always adding one more frame pass the sentinel frame.
This frame is always _Closure.call which is filtered out by the debugger
already. However when --optimization-counter-threshold=5, _Closure.call was
inlined and we ended up appending the inliner to the stack trace. The
inliner is not filtered out by the debugger so we got an extra frame in
the stack trace.
Fixes#28861
BUG=
R=fschneider@google.com
Review-Url: https://codereview.chromium.org/2707413002 .
UX improvements:
- [x] Stop printing the suffix <%s_async_body> and <%s_async_gen_body> for the generated closures.
Fixes#28743
- [x] Don't include the duplicate frame below the asynchronous suspension marker.
Fixes#28742
Bug fixes:
- [x] Fix service protocol enum naming so that it is consistent with other enums.
Fixes#28726
Misc:
- [x] Stop using package:stack_trace now that the VM does it for us.
BUG=
R=asiva@google.com, devoncarew@google.com, rmacnak@google.com
Review-Url: https://codereview.chromium.org/2690683002 .
Delete Breakpoint objects from the C heap when they are no longer needed.
Also delete inactive code breakpoint objects more aggressively.
This should fix the memory leaks reported in #28348.
General cleanup of breakpoint handling code and comments.
BUG=#28348
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2689623002 .
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/27661R=asiva@google.com, rmacnak@google.com
Comparisons: https://docs.google.com/a/google.com/document/d/10r6jEqr8OCiDZ4y9SYU_uOimcHiOGAZMly2ghTErALI/edit?usp=sharing
Review-Url: https://codereview.chromium.org/2646443005 .
This introduces
- a list of valid token positions, so debugging actually
starts to work, and the observatory can be loaded without crash.
- a list of valid yield positions, so stepping over await stuff
works as expected.
- Adding "DebugStepCheckInstr" to the kernel generated il so stepping
over await stuff works as expected, we can break in empty methods etc.
With this, approximately 80% of the service tests pass in kernel mode.
R=kmillikin@google.com
Committed: https://github.com/dart-lang/sdk/commit/2d5147be9d7435c06dd892d145d8717b6d1f62d5
Review-Url: https://codereview.chromium.org/2632183002 .
This introduces
- a list of valid token positions, so debugging actually
starts to work, and the observatory can be loaded without crash.
- a list of valid yield positions, so stepping over await stuff
works as expected.
- Adding "DebugStepCheckInstr" to the kernel generated il so stepping
over await stuff works as expected, we can break in empty methods etc.
With this, approximately 80% of the service tests pass in kernel mode.
R=kmillikin@google.com
Review-Url: https://codereview.chromium.org/2632183002 .
The synthetic call to completeError has the function end as a token position.
This caused the < comparison to fail, and not find the correct context level
when creating a stacktrace in the debugger.
Fixes#28443R=hausner@google.com
Review-Url: https://codereview.chromium.org/2646093006 .
Utilize the offsets added in previous CLs.
While this doesn't by it self give anything that resembles
a good debugging experience, it should now be possible to
set *some* breakpoints and actually break on them.
Because of the way observatory works (and because of an
unfinished Script::GenerateLineNumberArray (for kernel))
the formatting of the code you try to load up and 'debug'
has to be quite specific (e.g. no indentation at all),
and even then it mostly doesn't work.
This is step #3 in introducing these things, next step(s) will be
fixing stuff like the above.
R=kmillikin@google.com
Review-Url: https://codereview.chromium.org/2628693004 .
Siva Chandra