![]() The main contribution of this CL is unification of disparate handling of various functions like `Future.timeout`, `Future.wait`, `_SuspendState.createAsyncCallbacks` and `_SuspendState._createAsyncStarCallback` into a single `@pragma('vm:awaiter-link')` which allows Dart developers to specify where awaiter unwinder should look for the next awaiter. For example this allows unwinding to succeed for the code like this: Future<int> outer(Future<int> inner) { @pragma('vm:awaiter-link') final completer = Completer<int>(); inner.then((v) => completer.complete(v)); return completer.future; } This refactoring also ensures that we preserve information (including Function & Code objects) required for awaiter unwinding across all modes (JIT, AOT and AOT with DWARF stack traces). This guarantees users will get the same information no matter which mode they are running in. Previously we have been disabling awaiter_stacks tests in some AOT modes - which led to regressions in the quality of produced stacks. This CL also cleans up relationship between debugger and awaiter stack returned by StackTrace.current - which makes stack trace displayed by debugger (used for stepping out and determinining whether exception is caught or not) and `StackTrace.current` consistent. Finally we make one user visible change to the stack trace: awaiter stack will no always include intermediate listeners created through `Future.then`. Previously we would sometimes include these listeners at the tail of the stack trace, which was inconsistent. Ultimately this means that code like this: Future<int> inner() async { await null; // asynchronous gap print(StackTrace.current); // (*) return 0; } Future<int> outer() async { int process(int v) { return v + 1; } return await inner().then(process); } void main() async { await outer(); } Produces stack trace like this: inner <asynchronous suspension> outer.process <asynchronous suspension> outer <asynchronous suspension> main <asynchronous suspension> And when stepping out of `inner` execution will stop at `outer.process` first and the next step out will bring execution to `outer` next. Fixes https://github.com/dart-lang/sdk/issues/52797 Fixes https://github.com/dart-lang/sdk/issues/52203 Issue https://github.com/dart-lang/sdk/issues/47985 TEST=ci Bug: b/279929839 CoreLibraryReviewExempt: CL just adds @pragma to facilitate unwinding Cq-Include-Trybots: luci.dart.try:vm-aot-linux-product-x64-try,vm-aot-linux-debug-x64-try,vm-aot-linux-release-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-aot-dwarf-linux-product-x64-try Change-Id: If377d5329d6a11c86effb9369dc603a7ae616fe7 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311680 Reviewed-by: Alexander Markov <alexmarkov@google.com> Commit-Queue: Slava Egorov <vegorov@google.com> |
||
---|---|---|
.. | ||
bin | ||
lib | ||
test/convert | ||
testcases/convert | ||
.gitignore | ||
analysis_options.yaml | ||
AUTHORS | ||
CHANGELOG.md | ||
LICENSE | ||
OWNERS | ||
pubspec.yaml | ||
README.md |
This package provides libraries and a utility for decoding non-symbolic stack traces generated by an AOT-compiled Dart application.
Converting stack traces
In some modes of AOT compilation, information on mapping execution points to source locations is no longer stored in the Dart image. Instead, this information is translated to separately stored debugging information. This debugging information can then be stripped from the application before shipping.
However, there is a drawback. Stack traces generated by such an application no longer includes file, function, and line number information (i.e., symbolic stack traces). Instead, stack trace frames simply include program counter information. Thus, to find the source information for these frames, we must use the debugging information. This means either keeping the original unstripped application, or saving the debugging information into a separate file.
Given this debugging information, the libraries in this package can turn
non-symbolic stack traces back into symbolic stack traces. In addition, this
package includes a command line tool decode
whose output is the same as its
input except that non-symbolic stack traces are translated.
Using decode
Take the following Dart code, which we put in throws.dart
. The inlining
pragmas are here just to ensure that bar
is inlined into foo
and that foo
is not inlined into bar
, to illustrate how inlined code is handled in the
translated output.
@pragma('vm:prefer-inline')
bar() => throw Null;
@pragma('vm:never-inline')
foo() => bar();
main() => foo();
Now we run the following commands:
# Make sure that we have the native_stack_traces package.
$ dart pub global activate native_stack_traces
# We compile the example program, removing the source location information
# from the snapshot and saving the debugging information into throws.debug.
$ dart compile exe -S throws.debug throws.dart
# Run the program, saving the error output to throws.err.
$ ./throws.exe 2>throws.err
# Using the saved debugging information, we can translate the stack trace
# contained in throws.err to its symbolic form.
$ dart pub global run native_stack_traces:decode translate -d throws.debug -i throws.err
Features and bugs
Please file feature requests and bugs at the issue tracker.