Commit a52f2b9 which reworked awaiter stack unwinding and its
integration with debugger introduced the following regression:
it stopped treating `Future` listeners which had both `onValue`
and `onError` callbacks as catch all exception handlers. Only
listners with `onError` callback (those created with
`Future.onError`) were treated as a catch all handler.
This meant that debugger started to treat exceptions in the
code below as uncaught:
```
Future<void> foo() {
await 0;
throw '';
}
await foo().then(..., onError: (e, st) {
});
```
This change fixes this regression by checking if
`FutureListener.state & stateCatchError != 0` instead of
more narrow `FutureListener.state == stateCatchError` which
only detects listeners which only catch errors but do not
handle values. The new predicate matches
`FutureListener.handlesError`.
This relands 38e0046cad
with a fix to ensure that we correctly detect `onError`
callbacks which simply forward to a suspended async
function. We do this by marking FutureListener's that originate
from `await` using a bit in the state.
Fixes https://github.com/dart-lang/sdk/issues/53334
TEST=service/pause_on_unhandled_async_exceptions{_zones,}_test
Fixed: 53334
CoreLibraryReviewExempt: No fundamental changes to _FutureListener implementation, just additional bit to detect that this listener originates from await
Change-Id: I90385fc619cbb52925e075dd5c7b171a31ca4cab
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323481
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This reverts commit 38e0046cad.
Reason for revert: https://github.com/flutter/flutter/issues/133677
Original change's description:
> [vm] Treat Future.then(..., onError:...) as catch all handler
>
> Commit a52f2b9 which reworked awaiter stack unwinding and its
> integration with debugger introduced the following regression:
> it stopped treating `Future` listeners which had both `onValue`
> and `onError` callbacks as catch all exception handlers. Only
> listners with `onError` callback (those created with
> `Future.onError`) were treated as a catch all handler.
>
> This meant that debugger started to treat exceptions in the
> code below as uncaught:
>
> ```
> Future<void> foo() {
> await 0;
> throw '';
> }
>
> await foo().then(..., onError: (e, st) {
>
> });
> ```
>
> This change fixes this regression by checking if
> `FutureListener.state & stateCatchError != 0` instead of
> more narrow `FutureListener.state == stateCatchError` which
> only detects listeners which only catch errors but do not
> handle values. The new predicate matches
> `FutureListener.handlesError`.
>
> Fixes https://github.com/dart-lang/sdk/issues/53334
>
> TEST=service/pause_on_unhandled_async_exceptions_test
>
> Fixed: 53334
> Change-Id: I374114b7a7b2ef86b7ed6bf7d5e7cf71ba6054dc
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323280
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
> Reviewed-by: Ben Konyi <bkonyi@google.com>
> Commit-Queue: Slava Egorov <vegorov@google.com>
Change-Id: Id20a6929aac93511173c7467caee91e2488696ed
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323429
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit a52f2b9 which reworked awaiter stack unwinding and its
integration with debugger introduced the following regression:
it stopped treating `Future` listeners which had both `onValue`
and `onError` callbacks as catch all exception handlers. Only
listners with `onError` callback (those created with
`Future.onError`) were treated as a catch all handler.
This meant that debugger started to treat exceptions in the
code below as uncaught:
```
Future<void> foo() {
await 0;
throw '';
}
await foo().then(..., onError: (e, st) {
});
```
This change fixes this regression by checking if
`FutureListener.state & stateCatchError != 0` instead of
more narrow `FutureListener.state == stateCatchError` which
only detects listeners which only catch errors but do not
handle values. The new predicate matches
`FutureListener.handlesError`.
Fixes https://github.com/dart-lang/sdk/issues/53334
TEST=service/pause_on_unhandled_async_exceptions_test
Fixed: 53334
Change-Id: I374114b7a7b2ef86b7ed6bf7d5e7cf71ba6054dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323280
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
When evaluating an expressino at a breakpoint that's inside a closure,
the closure may refer to anything it closes over. That includes the
`this` from an enclosing method.
So depending on whether a closure's parent chain is an instance method
or a static method, the expression evaluation function is going to be an
instance method or a static method.
=> We walk up the parent chain to determine the correct enclosing class.
=> This avoids making a Type object with a cid from a top-level class (see [0])
Handling this correctly will now try to get the `this` when invoking an
eval function that has an enclosing instance method. Though we may often
have "<optimized out>" the `this` (e.g. due to not capturing it in
closure context chain).
=> We still allow running the expression evaluation function in this
case, but only if the expression being evaluated doesn't access `this`.
A similar issue occurs when trying to use variables in the eval
expression that the closure didn't capture. This results in a confusing
CFE compile-time error. This is a separate issue and tracked in [1].
=> We update the test to distinuish the cases that this CL makes passing
and those that are failing due to [1].
Fixes [0] https://github.com/dart-lang/sdk/issues/53061
See also [1] https://github.com/dart-lang/sdk/issues/53087
TEST=Fixes part of service/evaluate_activation_test failures
Change-Id: I3bb24e7338c7b2f12d5340311d944cb59a455641
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317540
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Creation of AppJit snapshot will not include the source of [Script]
objects (see `UntaggedScript::snapshot_to`). As a result there's no
point in letting the CFE embed the sources into the kernel if we
only use it to create an AppJit snapshot.
This is also in line with build rules for our dart-sdk, where we do the
kernel compilation separately, see utils/application_snapshot.gni:
```
template("application_snapshot") {
...
# Build the kernel file using the prebuilt VM to speed up the
# debug and simulator builds.
prebuilt_dart_action(target_name + "_dill") {
...
args = [
...
"--no-embed-sources",
...
]
[[[
}
...
}
```
TEST=ci
Change-Id: I4e17e49dc21af6102d62c2278dbd6ebbe387f7e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313560
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
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>
We no longer rewrite suspendable function into closures nested
inside the original function, so the whole synthetic async breakpoint
machinery is not needed.
Refactor `Breakpoint` class to make one-shot and per-closure
separate properties of breakpoint, which allows creating
one-shot-per-closure breakpoints.
TEST=existing service tests
Change-Id: I208afe13f36efa40f5746e44867bd24684cf5f03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310601
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Derek Xu <derekx@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Some of the service tests contain LINE_*
constants which match line numbers of `// LINE_*`
comments in the body of the test. Previously
we would manually maintain these constants,
which is rather tedious.
This CL adds a scripts for updating the
constants automatically.
TEST=manually tested the tool
Change-Id: I3a5cdbd4cae2ab6eaec51c9bb5f48b351bfbbd7a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310602
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
In Flutter hot reload, the flutter_tools are calling the `getIsolate`
to read the pause state of the isolate, which returns a full list of
libraries loaded in the isolate. The size of the return object grow
linearly to the number of Dart files, which can take ~500ms to transfer
for a large app.
This change adds a new method to only read what is needed.
TEST=pkg/vm_service/test/get_isolate_pause_event_rpc_test.dart
Change-Id: If19910cb3ff5d5057932551ac738afd3c3136fac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305362
Reviewed-by: Ben Konyi <bkonyi@google.com>
Auto-Submit: Chingjun Lau <chingjun@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
This field was supposed[1] to replace Stack.asyncCausalFrames but IDEs
and other service protocol users never adopted it.
The mechanism for collecting awaiterFrames and asyncCausalFrames
was originally considerably different, but we have since unified
both[2] after we switched to lazy async stack traces[3].
Today the only differences between the two are:
- asyncCausalFrames represens async gaps explicitly, while
awaiterFrames does not;
- when asynchronous function is running its synchronous part
before the first suspension awaiterFrames will still represent
the corresponding frame as an asynchronous activation, while
asyncCausalFrames will treat the same frame as regular frame.
Consequently having this field does not add any value.
This CL removes it from the response and updates all tests to
test against asyncCausalFrames.
[1]: https://codereview.chromium.org/2692803006/
[2]: https://dart-review.googlesource.com/c/sdk/+/167561
[3]: https://github.com/dart-lang/sdk/issues/37668
Tested: pkg/vm_service, service, service_2
Bug: https://github.com/dart-lang/sdk/issues/51763
Change-Id: If2b035a8840047423b8ed8ce3b5d81155e9f38d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/301062
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
TEST=Checked that Observatory's timeline view was still able to load CPU
samples correctly, and ensured that samples retrived using
getPerfettoCpuSamples were the same as the ones shown in Observatory.
Change-Id: I9b58cd32bc9a1c08848718f25f10db9fa6d4d241
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297760
Commit-Queue: Derek Xu <derekx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Makes `Iterable` a mixin class with a `const` constructor,
and `IterableBase` and `IterableMixin` (to-be-deprecated) aliases
for it.
Combining everything in one place avoids (some) code
duplication.
Also gave the methods a quick overhaul for formatting,
removing uses of `late` and unnecessary element accesses,
and some general tweaks.
CoreLibraryReviewExempt: Refactoring of redundant types.
Tested: Refactoring. If existing tests work, it works.
Change-Id: Ie49a88f713d386d2d118c53606a71bdd50e1eb11
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287600
Reviewed-by: Brian Quinlan <bquinlan@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Pure interfaces made `interface`s
implementation classes which cannot/should not be extended made `final`.
A class like `HasHMap` which provides the `Map` interface,
and no implementation except factory constructors
for internal implementations, is made `final`.
Unified {List,Set,Map}{Base,Mixin} into their `Base` class.
Deprecations are retained in comments for now, to be landed
separately. Search for '// TODO: @Deprecated'.
Tested: No new test, only adding restrictions on use.
CoreLibraryReviewExempt: Everybody's on vacation, everybody everywhere.
Change-Id: Ia83b8a3bb20b5b214546b328d4492de6658253db
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288240
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
The Windows and MacOS file system can be case insensitive, so the following
two URIs can be equivalent:
- file:///c:/foo/bar
- file:///C:/Foo/Bar
Since it's possible for tooling to request a mapping for a URI that
isn't an exact case-sensitive match to that found in the URI mappings
cache, requesting a mapping for the inexact match will fail even though
the paths are potentially equivalent.
This change allows for lookupPackageUris and lookupResolvedPackageUris
to correctly handle paths that are not case-sensitive matches to entries
in the URI mappings cache on Windows and MacOS.
TEST=uri_mappings_lookup_test.dart
Change-Id: I35134c47bf3bd04bc452373b31b4eb5893ba1435
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288821
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
- Update options for existing configurations.
- Add one new configuration for running _2 test suites.
- Rename builders and update to run new configurations.
Tested: Tested with led runs.
Change-Id: I87de456b6b2e53d9e211cbd716fef18910aba69c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/281348
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
This reverts commit c67fac9cb4.
Reason for revert: Regresses `dart:io` performance and causes
failures.
https://github.com/dart-lang/sdk/issues/51639
Original change's description:
> [vm] Remove tcmalloc and malloc profiler.
>
> The standalone VM originally began statically linking tcmalloc to work around bugs in the system malloc for Fiber. Later it used tcmalloc's hooks to implement a profiler, but this is rarely used since it is only available in debug mode, misses early allocations, and often misses late allocations from an exhausted sample buffer. Removing it altogether avoids build complexity around which combinations of compiler/architecture/sysroot support tcmalloc, and reduces binary size.
>
> TEST=ci
> Change-Id: I4b259e18b82b2d12a2a60962aabf83bd8d997d19
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286120
> Reviewed-by: Ben Konyi <bkonyi@google.com>
> Commit-Queue: Ryan Macnak <rmacnak@google.com>
Change-Id: I4395edd6f5bd7e26b4e38f4d931ad2ea67afba18
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286925
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
The standalone VM originally began statically linking tcmalloc to work around bugs in the system malloc for Fiber. Later it used tcmalloc's hooks to implement a profiler, but this is rarely used since it is only available in debug mode, misses early allocations, and often misses late allocations from an exhausted sample buffer. Removing it altogether avoids build complexity around which combinations of compiler/architecture/sysroot support tcmalloc, and reduces binary size.
TEST=ci
Change-Id: I4b259e18b82b2d12a2a60962aabf83bd8d997d19
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286120
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Ryan Macnak