This is follow up to commit cb0c2bf5ed.
SampleBlockProcessor only enters isolate group and not a specific
isolate so the code must not rely on thread->isolate(). This fixes two
places where this was not the case:
* ProfileBuilder::IsPCInDartHeap
* UserTags::TagName
pkg/dds/test/get_cached_cpu_samples_test was supposed to cover this but
it has two problems:
First I observed that SampleBlockProcessor never gets a chance to
process a block if mutator thread always gets to it first (via a
scheduled interrupt), so this code is not well exercised. I started by
adding a variant of the test where interrupts are inhibited via a
vm:unsafe:no-interrupts pragma - which revealed the crashes in the
SampleBlockProcessor code.
This revealed the second problem: get_cached_cpu_samples_test does not
actually fail if testee crashes during the test, it just silently
completes with success. This seems to happen because disposal of
VmService connection is not forwarded into the future on which the test
is awaiting - and the whole process just exits once VmService connection
to the testee disappears (because all ports are closed, no pending
activity is possible after that one). I have fixed this by adding a
helper function which checks that connection to VmService only goes away
when we dispose it.
Note: there is another obvious issue here, which I am leaving unfixed
for now. SampleBlockProcessor calls UserTags::TagName in a way that can
race with isolate itself modifying the table. I think this race is
extremely unlikely but it can cause crashes on ARMs with its weak memory
model (e.g. we might end up reading garbage due to the reordering of
stores).
TEST=pkg/dds/test/get_cached_cpu_samples_test
Change-Id: Iee15ec2b019928b798c312e63edc76696abf5527
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/426300
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
The change at https://dart-review.googlesource.com/c/sdk/+/410760 to fix a race incorrectly assumed that once we had handled startup for a thread, we would never need to send an automatic resume again. However this was not the case - after a hot reload, we need to resume the thread even though we had technically already handled startup.
This is essentially a partial revert of 84e6ed0784, with a test to verify we trigger readyToResume on PausePostRequest.
Change-Id: I1e171043f04f38dd6f52e1692d9257d34e5248be
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/416580
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Derek Xu <derekx@google.com>
The DAP tests have some debug logging that prints if a request/event takes longer than 10 seconds to arrive. In the case where tests run quickly and the DAP client is torn down, these delays cause the test run to stay alive for 10 sec unnecessarily (and print irrelevant warnings).
This changes that code to check periodically instead, and exits early if the client is torn down avoiding both the 10s wait and the spurious warning.
Change-Id: Ic07826942e8ae307867820020b30595a42e68d15
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/411680
Reviewed-by: Derek Xu <derekx@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
While reviewing logs for flaky DAP tests, I found that these tests have been failing sometimes with errors that look like the isolate might not have paused on the `debugger()` call yet:
```
evaluateInFrame: (113) Expression compilation error
_buildExpressionEvaluationScope: invalid 'frameIndex' parameter: 0
```
and
```
evaluateInFrame: (113) Expression compilation error
org-dartlang-debug:synthetic_debug_expression:1:1: Error: Undefined name 'myInstance'.
myInstance
^^^^^^^^^^
```
This waits for the isolate to be paused, not just runnable, which I think might fix this.
Change-Id: Ib1d6b1c44a7ef93452065aa43c4d05058914db28
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/395302
Reviewed-by: Derek Xu <derekx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
devtools_shared 11.0.0 updates some signatures to use a new DTDInfo class to support both a local + exposed URI for DTD. A new CLI flag `--dtd-exposed-uri` for `devtools server` allows passing this second URI.
The DevTools server will use `--dtd-uri` to connect to DTD itself, but serve `--dtd-exposed-uri` to the frontend.
`--dtd-exposed-uri` is entirely optional and if not supplied, the value from `--dtd-uri` will be used in its place.
Change-Id: I5ab052ff9c4e7b2b186c1592f1ba2d63b7711113
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/383400
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Kenzie Davisson <kenzieschmoll@google.com>
Reviewed-by: Kenzie Davisson <kenzieschmoll@google.com>
Part of the process to remove uses of
DartDevelopmentService.startDartDevelopmentService in favor of launching
with `dart development-service`.
Change-Id: I857aee932c0b2fc6ae2172eb106b78c76d536295
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/380760
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Derek Xu <derekx@google.com>
Before this change, Service.controlWebServer would block on the first
call, waiting until DDS had finished starting to respond, while
subsequent calls would return as soon as the VM service HTTP server had
started, exposing the internal VM service URI. This could result in
clients connecting directly to the VM service while DDS was
initializing, only for them to be disconnected immediately once DDS
invoked _yieldControlToDDS.
Fixes https://github.com/dart-lang/sdk/issues/56254
TEST=pkg/dds/test/control_web_server_regress_56254_test.dart
Change-Id: Ic707882263caa9ffe832e768c37492dfde43b611
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/379700
Auto-Submit: Ben Konyi <bkonyi@google.com>
Reviewed-by: Derek Xu <derekx@google.com>
Reviewed-by: Liam Appelbe <liama@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Capturing debug logs that includes VM Service traffic is useful for debugging. Previously with the new DAPs, this could only be enabled at session start which meant users would have to capture very large log files.
This adds the ability to enable/disable this logging while a debug session is already running. A related change in Dart-Code will send this request when you use the "Capture Debugging Logs" command, so you can start a debug session, get to the point of reproducing an issue, and then just capture the relevant logs (VM Service traffic included).
Fixes https://github.com/Dart-Code/Dart-Code/issues/5197
Change-Id: I7e766e57bd80819eb5da164e544903fae23927ed
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/377222
Commit-Queue: Helin Shiah <helinx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
This reverts commit 3370a4e393.
Reason for revert: Fixes landed in google3 (cl/650630536).
Original change's description:
> Revert "Reapply "[ Service ] Start DDS and serve DevTools when the VM service is started via dart:developer""
>
> This reverts commit 44d4451476.
>
> Reason for revert: b/350443042
>
> Original change's description:
> > Reapply "[ Service ] Start DDS and serve DevTools when the VM service is started via dart:developer"
> >
> > In the previous version of this change, if the user had 'dart' on their
> > PATH and invoked 'dart compile js' (which spawns the VM service after
> > compilation completes), the VM service would attempt to spawn DDS using
> > './dart' as the executable path instead of 'dart'. This would result in
> > DDS failing to start, causing the VM to print an error and hang.
> >
> > This updated change checks to see if the parent directory of
> > `Platform.executable` is '.' and then verifies if './dart' exists or
> > not. If it doesn't, 'dart' is likely on the user's PATH and should be
> > used directly as the executable path.
> >
> > See https://github.com/dart-lang/sdk/issues/56087 for details.
> >
> > This reverts commit 4b88698e48.
> >
> > TEST=pkg/dds/test/control_web_server_starts_dds_with_dart_on_path_test.dart
> >
> > Change-Id: Id0f1dadd01d9202cbf7717f31393b43171cf3968
> > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373561
> > Auto-Submit: Ben Konyi <bkonyi@google.com>
> > Reviewed-by: Derek Xu <derekx@google.com>
> > Commit-Queue: Ben Konyi <bkonyi@google.com>
>
> Change-Id: I424c4b91b0b108ae4c9dffa0059ed90c918897e3
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373744
> Reviewed-by: Siva Annamalai <asiva@google.com>
> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
> Reviewed-by: Srujan Gaddam <srujzs@google.com>
> Commit-Queue: Siva Annamalai <asiva@google.com>
> Auto-Submit: Ivan Inozemtsev <iinozemtsev@google.com>
Change-Id: Id7ddff5a80399203fb8058d84bc89fda2073da95
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/375000
Auto-Submit: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
Reviewed-by: Derek Xu <derekx@google.com>
This reverts commit 44d4451476.
Reason for revert: b/350443042
Original change's description:
> Reapply "[ Service ] Start DDS and serve DevTools when the VM service is started via dart:developer"
>
> In the previous version of this change, if the user had 'dart' on their
> PATH and invoked 'dart compile js' (which spawns the VM service after
> compilation completes), the VM service would attempt to spawn DDS using
> './dart' as the executable path instead of 'dart'. This would result in
> DDS failing to start, causing the VM to print an error and hang.
>
> This updated change checks to see if the parent directory of
> `Platform.executable` is '.' and then verifies if './dart' exists or
> not. If it doesn't, 'dart' is likely on the user's PATH and should be
> used directly as the executable path.
>
> See https://github.com/dart-lang/sdk/issues/56087 for details.
>
> This reverts commit 4b88698e48.
>
> TEST=pkg/dds/test/control_web_server_starts_dds_with_dart_on_path_test.dart
>
> Change-Id: Id0f1dadd01d9202cbf7717f31393b43171cf3968
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373561
> Auto-Submit: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Derek Xu <derekx@google.com>
> Commit-Queue: Ben Konyi <bkonyi@google.com>
Change-Id: I424c4b91b0b108ae4c9dffa0059ed90c918897e3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373744
Reviewed-by: Siva Annamalai <asiva@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Auto-Submit: Ivan Inozemtsev <iinozemtsev@google.com>
In the previous version of this change, if the user had 'dart' on their
PATH and invoked 'dart compile js' (which spawns the VM service after
compilation completes), the VM service would attempt to spawn DDS using
'./dart' as the executable path instead of 'dart'. This would result in
DDS failing to start, causing the VM to print an error and hang.
This updated change checks to see if the parent directory of
`Platform.executable` is '.' and then verifies if './dart' exists or
not. If it doesn't, 'dart' is likely on the user's PATH and should be
used directly as the executable path.
See https://github.com/dart-lang/sdk/issues/56087 for details.
This reverts commit 4b88698e48.
TEST=pkg/dds/test/control_web_server_starts_dds_with_dart_on_path_test.dart
Change-Id: Id0f1dadd01d9202cbf7717f31393b43171cf3968
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373561
Auto-Submit: Ben Konyi <bkonyi@google.com>
Reviewed-by: Derek Xu <derekx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This reverts commit 64d4689a78.
Reason for revert: Platform.executable doesn't return a path, just an executable name, which can cause breakages.
TEST=ci
Original change's description:
> [ Service ] Start DDS and serve DevTools when the VM service is started via dart:developer
>
> TEST=pkg/dds/test/control_web_server_starts_dds_test.dart
>
> Change-Id: I2e51783592912e5a719685f2ab5e7537b7a59586
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366560
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Derek Xu <derekx@google.com>
Change-Id: I4ceaee4b5ca8f5557e90cd914ee69fe9aa5f85a7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/373381
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Derek Xu <derekx@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
This moves the CLI logic into lib/src/dds_cli_entrypoint.dart so it can
be invoked by a custom google3 entrypoint (bin/dds.dart can't be
imported using a package: URI).
Since google3 will be able to perform some custom configuration of DDS,
google3 related logic (e.g., `BazelUriConverter`) is also removed. This
is technically a breaking change, but should be safe as this
functionality isn't currently being used.
Change-Id: I54d8a9927ff2df70e013ca5c8bc1d510b0b95f02
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/371520
Reviewed-by: Derek Xu <derekx@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
Auto-Submit: Ben Konyi <bkonyi@google.com>
When a class contains both a field and getter with the same name, we'd include both in the `variables` response. In most cases these are the same value (although it's not guaranteed).
I've chosen to just hide the field in this case and always show the result from evaluating the getter (since I think that's what the user would expect, even in the case where they happen to have different values). Another option could be to show both (but change the name so that fields/getters are shown differently), however in that would change the display (for example adding `get ` in front of all getters) we should probably only do that if it's clear there is demand for it.
Fixes https://github.com/Dart-Code/Dart-Code/issues/5128
Change-Id: I9e23d22a844ee22c38988456b1f275422c5c9e04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/370640
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Derek Xu