- [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 .
- [x] Add three public fields to the "BoundVariable" service type: declarationTokenPos, visibleStartTokenPos, and visibleEndTokenPos. (naming suggestions welcome!)
- [x] Extend LocalVarDescriptors to hold the declaration token position (it already had the scope visibility boundaries).
- [x] Extend ContextScope to hold the declaration token position.
- [x] Add a unit test which verifies this works for local variables, function parameters, and closure captured variables.
Fixes https://github.com/dart-lang/sdk/issues/25569
BUG=
R=rmacnak@google.com
Review URL: https://codereview.chromium.org/2419013004 .
- [x] Make `reloadSources` RPC public.
- [x] Add an optional 'pause' parameter to `reloadSources`. When set to true, the isolate will enter the debug pause loop immediately after reloading sources and before resuming execution. This makes it possible for debugger clients to set breakpoints before resuming.
- [x] Add reload_sources_test which tests pausing after reload.
- [x] Fix a bug in `GetVarDescriptors` where a null code object could be used.
R=turnidge@google.com
Review URL: https://codereview.chromium.org/2411153002 .
When async-stepping over an await statement that follows a previous
async-step command, ensure that the synthetic breakpoint at the
beginning of the async closure is not accidentally deleted.
Removing a test that depends on minute details of the internal
implementation of async-step commands.
Adding new test that checks for multiple consecutive async-step
commands.
Note that debugger.cc seems to contain a memory leak. Breakpoint
objects are not deleted (deallocated) when RemoveBreakpoint()
is called. Will address this in a separate CL.
BUG=#27238
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org/2366463002 .
Ryan Macnak