There is a synthetic try/catch within a try/finally block.
When trying to assess whether an exception is caught, the debugger
should skip such generated try/catch blocks. Otherwise, it considers
that try/finally actually handles the exception, which is wrong.
Fixes https://github.com/dart-lang/sdk/issues/45684
TEST=runtime/observatory{,_2}/tests/service{,_2}/regress_45684_test.dart
Change-Id: I60e8837204cf97ee1ab02ffd03364e7f69857004
Fixed: 45684
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/196124
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
objects
It's possible for scripts to appear in multiple components provided by
the front end in certain situations (e.g., mixin applications in
different libraries). Previously when trying to set a breakpoint, if
multiple scripts were found matching the target URI the debugger would
give up and not set the breakpoint.
This change allows for multiple Scripts to be associated with a
BreakpointLocation.
Fixes https://github.com/flutter/flutter/issues/66832
TEST=runtime/observatory_2/tests/service_2/sdk_break_with_mixin_test.dart
Change-Id: I935721f4753675a9a2051a71cc1720e590f8d4f6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/195664
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
In AppJIT mode we run from a snapshot and won't have an incremental
compiler available. That also means expression evaluation is not
supported.
The specific test that was failing was
service_2/evaluate_activation_in_method_class_test/service
though this CL skips all evaluation tests.
The CL also align the service and service_2 status files more.
TEST=Only updates status file to skips tests.
Change-Id: I8dbb3aeeb686370d898c59da3729f5e0c52df411
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/194685
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Added entry-point pragmas to prevent obfuscation of global vars.
Removed expectation checking for standard library `Expando` class name.
Closes: https://github.com/dart-lang/sdk/issues/45422
TEST=Fixes various service_2 tests in obfuscation mode.
Change-Id: I91bb856c7f1ff44afe1cceec8e94e3b97ab56e44
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-obfuscate-linux-release-x64-try
Fixed: 45422
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/192681
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
responses
Allows for comparing @Instances and Instances with allocation traces and
heap snapshot entries.
TEST=pkg/vm_service/test/get_allocation_traces_test.dart
Change-Id: I6d021b0267f1595332475470961df6e35321ce80
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/188600
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
CodeBreakpoint class tracks patching of the call targets for the purpose of routing the call to the debugger runtime.
With this CL CodeBreakpoint instance is managed by GroupDebugger, debugger class owned by IsolateGroup, and can be associated with multiple BreakpointLocation, one location per isolate that set a breakpoint at particular code location.
TEST=observatory/tests/service/break_on_function_child_isolate_test
Issue https://github.com/dart-lang/sdk/issues/36097
Change-Id: I3b3d0974a0fb9668742e5c1e2a2ce13b84b1d630
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/190732
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The async, off-stack part of DebuggerStackTrace::CollectAwaiterReturn's
stack unwinding incorrectly looked on the stack instead of following
the Closure's awaiter chain.
This caused the async stack traces to be truncated and missing any
async frames, in turn causing ShouldPauseOnException to incorrectly
conclude no handler frame existing.
This would affect any case where the exception handling was located
around any except for the inner most awaiter.
TEST=Added regression test to pause_on_unhandled_exceptions_catcherror_test
Closes: https://github.com/dart-lang/sdk/issues/37953
Bug: https://github.com/dart-lang/sdk/issues/37953
Change-Id: I34a2b5ce3c7532032b2ef3dfbc2af7294d13a4c7
Cq-Do-Not-Cancel-Tryjobs: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/187405
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
In observatory there are two different ways to do expression evaluation.
One calls `evaluateInFrame` and catches the ServerRpcException thrown
when there's a compilation error. Another calls `evaluate` and does not
catch the ServerRpcException thrown when there's a compilation error.
This means, for instance, if evaluting an expression on an instance
and makes a typo there's suddenly a big box with scrambled javascript
on the top-right of the screen.
This CL:
* Handles the ServerRpcException thrown when there's a compilation error
for `evaluate` as well.
* Makes both `evaluate` and `evaluateInFrame` unpack the `details` sent
by the VM instead of printing out the textual representation of a map.
This means that you get an error message like
```
org-dartlang-debug:synthetic_debug_expression:1:1: Error: Getter not found: 'test'.
test
^^^^
```
instead of
```
{details: org-dartlang-debug:synthetic_debug_expression:1:1: Error: Getter not found: 'test'.
test
^^^^}
```
TEST=Existing test suites.
Change-Id: I2dc3f19f024e918e8d0e9b0f4166a4ef2c6cbd9b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/186292
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
This change adds two new RPCs and various new properties:
- getAllocationTraces
- setTraceClassAllocation
- classId and identityHashCode properties in CpuSample
- traceAllocations property in Class
TEST=get_allocation_traces_test.dart
package:vm_service has been regenerated for 3.43 of the service protocol
and is ready for a 6.1.0 release.
Change-Id: Ia8ed055423798d7d17fe9f5fd74efb4239b875fc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/182666
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Since loading kernel will affect all isolates within a group, there
should be nothing isolate-specific inside the kernel loader. To ensure
we don't have (or introduce) any accidental uses, we add a
NoActiveIsolateScope to the main parts of kernel loading.
Only loading of native extensions - done by the kernel loader -
currently requires an active isolate. The reason for this is that
loading native extensions happen by calling out to embedder, which calls
back into the VM using the our embedding API (which currently requires
an active isolate)
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Refactoring of existing implementation.
Change-Id: I96e64dbfe7148b76b8fa006fe5dbde8c1f904504
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/184269
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Previously, deferred imports were really deferred, and the VM would have needed to trigger more loading as part of checking the validity of a reload and handle the re-entrancy of the tag handler and restart the checking a reload: all messy control flow that was side-stepped by just erroring-out. Currently, the language and kernel are incapable of truly deferred imports, so we need only propagate the state bit that checks loadLibrary was called and completed before members are accessed through the deferred prefix.
TEST=deferred_import_reload_test
Bug: https://github.com/dart-lang/sdk/issues/26878
Bug: https://github.com/flutter/flutter/issues/73602
Change-Id: I48bf3e8331630b732d96393e02b12f86de8cc5b5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179620
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
_yieldControlToDDS
Instead of DDS failing to connect when there are existing clients
connected to the VM service, the VM service will now disconnect these
clients when _yieldControlToDDS is invoked.
If an existing DDS instance is already connected, existing clients will *not*
be disconnected and instead an error will be returned containing the URI of
the existing DDS instance.
TEST= runtime/observatory/tests/service/dds_disconnects_existing_clients_test.dart
Change-Id: I08e126d99f51ff14205f359a60ca802c27fd206d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178725
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Instead, split each old use into the following cases:
* If the TokenPosition value is expected to be a real token position,
then use TokenPosition::Pos().
* If the TokenPosition is being serialized in some way, then use
TokenPosition::Serialize() and change the place where the
TokenPosition is recreated to use TokenPosition::Deserialize().
* If the value of the TokenPosition is being printed for debugging
purposes, then just use TokenPosition::ToCString() instead.
That is, we try to pin down when token positions are expected to
be real vs. when other types of token positions can be found.
Another source of possible error when using token positions is to
convert between synthetic and real token positions. In the past,
synthetic token positions may have been based off real token positions,
but that is no longer the case. Thus, all methods that allow
that conversion have been removed, and instead there is a new static
method for constructing synthetic tokens from valid nonces.
This CL also makes it so that Pos() and relational operators on token
positions are only defined on real token positions, to avoid any
assumptions about what the value encoded in synthetic positions mean. To
help with cases where non-real token positions may occur, four helper
methods are added:
* TokenPosition::Min(a, b): A static method that returns the smallest
real token position provided. If neither `a` or `b` are real,
returns `a`.
* TokenPosition::Max(a, b): A static method that returns the largest
real token position provided. If neither `a` or `b` are real,
returns `a`.
* TokenPosition::IsWithin(start, end): Determines whether `this` falls
between `start` and `end` (inclusive). If `this` is non-real, then it
must be either `start` or `end` if synthetic, otherwise false.
Otherwise, we mimic the old style of range checking, which means that
non-real starts and ends are treated as less than every real token.
* TokenPosition::CompareForSorting(other): Unlike the relational
operators, provides a comparison between any types of token positions
for purposes such as sorting. Currently only used in the profiler.
It also changes TokenPosition::ToCString() to tag synthetic token
positions, so they can be distinguished from real ones at a glance.
TEST=Existing test suite on trybots, especially the observatory tests
which make heavy use of the debugger and the unit tests for the
profiler/source report modules.
Bug: https://github.com/dart-lang/sdk/issues/44436
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-nnbd-linux-debug-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-nnbd-linux-debug-x64-try,vm-kernel-linux-debug-x64-try,vm-kernel-linux-release-x64-try,vm-kernel-nnbd-linux-release-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-nnbd-linux-release-x64-try,vm-kernel-linux-product-x64-try,vm-kernel-precomp-linux-product-x64-try
Change-Id: Ic06aa0bc7a1f0fbac7257ed22ca5e7e0ccd7f3f2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174924
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
This CL makes use of the now included constant constructor coverage
in the dill file.
It works like this:
* When the CFE evaluates constants, every constant constructor
invocation evaluated saves the reference to the constructor in the
`Source` (from the Components uri to source table) for the callers
Library.
* This data is loaded into the VM in a "raw" format.
* When a request for coverage comes in, the VM - on top of the normal
coverage processing - goes through all scripts to find constant
constructor coverage for the requested script and offset. Note that
all scripts must be checked because library A can have evaluated a
constructor from library B - so even if only coverage for library B
was requested, library A has to be checked.
For all constructors found the start and end position is reported as
covered. Note that this does not mark any initializes and there are
(at least currently) no good way of marking which initializes were
evaluated (because it has to be stable across edits even when the
`advanced invalidation feature` is enabled).
* Note that the reason for the coverage to work on references - as
hinted above - is because we want it to be stable across hot reloads
even if/when advanced invalidation is enabled. This means, that
library A cannot record "positional coverage" for library B because
library B might get (for instance) new comments that will make any old
offsets invalid. By using references we always lookup in the current
world and use the correct offsets.
https://github.com/dart-lang/sdk/issues/38934
TEST=Existing test suite, new tests for the new coverage added.
Change-Id: I29531247a4b91a99d9a459cfdefbb9798e9c948f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175246
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Ben Konyi