This reverts commit 0ea18ffb36.
Reason for revert: Tree is on fire
Original change's description:
> [ Service / DDS ] Advertise DDS as the VM service, bump version to 4.0
>
> This change does the following:
> - The DDS URI will be reported by the VM as the VM service URI. If DDS
> disconnects, the VM service URI will be reported instead. This only
> impacts the standalone VM.
> - Updated the service protocol to 4.0 and removed the following
> deprecated functionality:
> - Client synchronization RPCs (these now live in DDS)
> - getWebSocketTarget (no longer needed as the VM service no longer
> tries to redirect web socket clients to DDS)
> - Regenerates package:vm_service based on the new spec, prepare for
> 5.0 release
>
> Change-Id: I8a2b401062342eb99b81ef10ef6926baa88f946e
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/160141
> Reviewed-by: Siva Annamalai <asiva@google.com>
TBR=bkonyi@google.com,rmacnak@google.com,asiva@google.com
Change-Id: I6a16e9fa7ceb18555d6424a169cfa811d3833419
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/160340
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This change does the following:
- The DDS URI will be reported by the VM as the VM service URI. If DDS
disconnects, the VM service URI will be reported instead. This only
impacts the standalone VM.
- Updated the service protocol to 4.0 and removed the following
deprecated functionality:
- Client synchronization RPCs (these now live in DDS)
- getWebSocketTarget (no longer needed as the VM service no longer
tries to redirect web socket clients to DDS)
- Regenerates package:vm_service based on the new spec, prepare for
5.0 release
Change-Id: I8a2b401062342eb99b81ef10ef6926baa88f946e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/160141
Reviewed-by: Siva Annamalai <asiva@google.com>
Capture content of request/response.
Changes about this cl:
1. The body of request will be written used by methods of `IOSink`. Each
operation will emit a single event on the same timeline task. Add() will
accept List<int> and write() works with strings. The data will remain
the same as what user has passed. With that being said, data coming from
add() will show a list of integers and a string representation if
write() is used.
2. The timeline of `HttpClientResponse` will be a child timeline of
corresponding `HttpClientRequest`. It will be recorded only if parent
request is recorded and logging flag is still set. If the flag is on
after the request is sent, the response will not be monitored.
3. `HttpClientResponse` is simply a stream. The timeline starts when
the response is received. But it is possible that users doesn't
read the content and close the program. In this case, timeline never
gets a proper close event. To have a close event, users has to call
listen().
4. This also fixes verify_http_time_line_test.dart. It was broken
and not checking correct events because of a typo.
Bug: https://github.com/dart-lang/sdk/issues/42952
Change-Id: I884db6405264a3ad9a03cecc8f5445dad4fb3e31
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157567
Commit-Queue: Zichang Guo <zichangguo@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
This adds a debugger mechanism to replace part of
--causal-async-stack's _asyncStackTraceHelper runtime entry.
It recognises async and async* functions and adds a synthetic
breakpoint on entry into the wrapped async_op, making sure we
don't get "synthetic" frames as we're stepping in and out of
the async code.
Change-Id: I1df6e6874de2fa9185f27a1a8873ad0071ad9fb6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/157480
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
When class table is shared between isolates in isolate group it should be visited only once in (IsolateGroup/Isolate)::VisitObjectPointers.
Visiting it more than once degrades performance and potentially causes bugs since not all visitors are idempotent(GC-related).
Bug: b/163063081
Change-Id: If56fab2401ca7afe654754fead74cefa233327f6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/158020
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
connect to DDS without relying on a redirect.
Some WebSocket implementations (particularly dart:html's) don't follow
redirects and don't provide the user with the message returned by the
server.
This CL adds 'getWebSocketTarget' as an RPC which returns the
URI that should be used by the client to connect directly to the proper
web socket target. In addition, the "implicit-redirect" forwarding has
been removed.
Change-Id: Iaf88c965f6fedfa6f63c28a08860a3c80388797c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/156485
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Introduces Dart_NewFinalizableHandle which does auto delete itself,
but does not allow accessing the weak referenced object.
Issue: https://github.com/dart-lang/sdk/issues/42312
Change-Id: I24ea732925122c453213c4fa3f629761c352f838
Cq-Include-Trybots:dart/try:vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64-try,app-kernel-linux-debug-x64-try,vm-kernel-linux-debug-ia32-try,vm-kernel-win-debug-x64-try,vm-kernel-win-debug-ia32-try,vm-kernel-precomp-linux-debug-x64-try,vm-dartkb-linux-release-x64-abi-try,vm-kernel-precomp-android-release-arm64-try,vm-kernel-asan-linux-release-x64-try,vm-kernel-msan-linux-release-x64-try,vm-kernel-precomp-msan-linux-release-x64-try,vm-kernel-linux-release-simarm-try,vm-kernel-linux-release-simarm64-try,vm-kernel-precomp-android-release-arm_x64-try,vm-kernel-precomp-obfuscate-linux-release-x64-try,dart-sdk-linux-try,analyzer-analysis-server-linux-try,analyzer-linux-release-try,front-end-linux-release-x64-try,vm-kernel-precomp-win-release-x64-try,vm-kernel-mac-debug-x64-try,vm-precomp-ffi-qemu-linux-release-arm-try,vm-kernel-nnbd-linux-debug-x64-try,analyzer-nnbd-linux-release-try,front-end-nnbd-linux-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154695
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This reverts commit bc4cb123a8.
Reason for revert: breaks crossword simarm tests https://ci.chromium.org/p/dart/builders/ci.sandbox/vm-kernel-precomp-linux-debug-simarm_x64/2619
Original change's description:
> Reland "[ VM / DartDev ] Launch DartDev in an isolate within a single main Dart process"
>
> This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
>
> By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
>
> VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
> Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
> Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/42092)
>
> This reverts commit 3849b5061c.
>
> Change-Id: I4fd3ba33840771a9f284d733c4a25fac6cde64ca
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154706
> Reviewed-by: Siva Annamalai <asiva@google.com>
TBR=bkonyi@google.com,asiva@google.com
Change-Id: I649d94c668417f2edbfd7039fa5c876e10dc32fe
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154800
Reviewed-by: Alexander Aprelev <aam@google.com>
This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/42092)
This reverts commit 3849b5061c.
Change-Id: I4fd3ba33840771a9f284d733c4a25fac6cde64ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154706
Reviewed-by: Siva Annamalai <asiva@google.com>
This reverts commit ffe258d2d4.
Reason for revert: Failures on bots
Original change's description:
> [ VM / DartDev ] Launch DartDev in an isolate within a single main Dart process
>
> This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
>
> By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
>
> VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
> Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
> Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/41978)
>
> Change-Id: I1c6b1425831b691ad20284716aa80f817dbaf607
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152588
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
TBR=bkonyi@google.com,rmacnak@google.com,asiva@google.com
Change-Id: Idb1d24a4524bdc3ccfb199a82710f3c0d9db539a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154702
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/41978)
Change-Id: I1c6b1425831b691ad20284716aa80f817dbaf607
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152588
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
A few people have expressed confusion about why the top-level size shown in the heap snapshot view does not correspond to the total in the allocation table view. The missing size is now shown.
Change-Id: Idc7e53cb6098263f9809d4bb7c3154a97c4ba3e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152408
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Before this change async activation frames didn't have local variables included into service json response, so user didn't see those local variables when paused at breakpoint in those frames.
Bug: b/159433735
Change-Id: Icdec6c8c0ef17541ef89e113d2f75718e4b35a0c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152103
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This reverts commit 65e3c9d3b1.
Reason for revert: package:logging, package:stack_trace and package:usage need to be migrated first.
Original change's description:
> [vm, service, observatory] Bang Bang (My Type System Shot Me Down).
>
> Port the service tests and Observatory to Dart 3.
>
> Changes from the original landing:
>
> - The old tests are copied to observatory_2 / service_2 so the service can still be tested when running a legacy mode program
> - The test harness is taught about 'service_2'
> - Observatory's package is added to front end's opt-in list
> - Fixed some places in the bot configuration matrix so ensure 'service' runs on legacy bots and 'service_2' on weak-mode bots
>
> The ported tests themselves are not changed.
>
> Change-Id: I1d7e5cc61cdc044e1985e851bea7fd8a18f7d810
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/149720
> Commit-Queue: Ryan Macnak <rmacnak@google.com>
> Reviewed-by: Ben Konyi <bkonyi@google.com>
TBR=bkonyi@google.com,rmacnak@google.com
Change-Id: I43b72f149d8d7e9fe06006cdd8593fed1726aa3a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152004
Reviewed-by: David Morgan <davidmorgan@google.com>
Commit-Queue: David Morgan <davidmorgan@google.com>
Port the service tests and Observatory to Dart 3.
Changes from the original landing:
- The old tests are copied to observatory_2 / service_2 so the service can still be tested when running a legacy mode program
- The test harness is taught about 'service_2'
- Observatory's package is added to front end's opt-in list
- Fixed some places in the bot configuration matrix so ensure 'service' runs on legacy bots and 'service_2' on weak-mode bots
The ported tests themselves are not changed.
Change-Id: I1d7e5cc61cdc044e1985e851bea7fd8a18f7d810
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/149720
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Final cleanup work before first full version of package:dds is
published:
- Added `getSupportedProtocols` RPC to the VM service protocol, which returns a
list of supported service protocols and extensions along with their version
information.
- Added `getDartDevelopmentServiceVersion` RPC to the DDS protocol.
- Misc code and dependency cleanup recommended by pub
Change-Id: If1bdf46852778adf31242122665c36b63106ad44
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/148224
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This is a reland of 604a366065
Original change's description:
> [ VM / DartDev ] Run all debugging sessions via 'dart run'
>
> Prior to this change, running `dart --observe foo.dart` would result in
> the DartDev flow being bypassed. While `dart foo.dart` will continue to
> bypass DartDev and be run directly, running either `dart --observe
> <vm-flags> foo.dart` or `dart --enable-vm-service <vm-flags> foo.dart`
> will result in the command being implicitly converted to `dart run
> --observe <vm-flags> foo.dart`. This is required for all standalone VM
> instances to run against DDS instead of the VM service directly.
>
> As usual, the DartDev flow can always be bypassed by providing the
> --disable-dart-dev flag.
>
> Change-Id: I211cd1ec4b1ec0e75ae0a568a66f1a0fc7b3852f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147342
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
Change-Id: I917d3056322d74766bdf376a3e28871ad5b66cfa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147980
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This reverts commit 604a366065.
Reason for revert: Breaks google3, see b/156414355
Original change's description:
> [ VM / DartDev ] Run all debugging sessions via 'dart run'
>
> Prior to this change, running `dart --observe foo.dart` would result in
> the DartDev flow being bypassed. While `dart foo.dart` will continue to
> bypass DartDev and be run directly, running either `dart --observe
> <vm-flags> foo.dart` or `dart --enable-vm-service <vm-flags> foo.dart`
> will result in the command being implicitly converted to `dart run
> --observe <vm-flags> foo.dart`. This is required for all standalone VM
> instances to run against DDS instead of the VM service directly.
>
> As usual, the DartDev flow can always be bypassed by providing the
> --disable-dart-dev flag.
>
> Change-Id: I211cd1ec4b1ec0e75ae0a568a66f1a0fc7b3852f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147342
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
TBR=bkonyi@google.com,rmacnak@google.com,asiva@google.com
Change-Id: I688a3779e7ccaf85a28dc4d6f5ccf23596109519
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147900
Reviewed-by: David Morgan <davidmorgan@google.com>
Commit-Queue: David Morgan <davidmorgan@google.com>
Prior to this change, running `dart --observe foo.dart` would result in
the DartDev flow being bypassed. While `dart foo.dart` will continue to
bypass DartDev and be run directly, running either `dart --observe
<vm-flags> foo.dart` or `dart --enable-vm-service <vm-flags> foo.dart`
will result in the command being implicitly converted to `dart run
--observe <vm-flags> foo.dart`. This is required for all standalone VM
instances to run against DDS instead of the VM service directly.
As usual, the DartDev flow can always be bypassed by providing the
--disable-dart-dev flag.
Change-Id: I211cd1ec4b1ec0e75ae0a568a66f1a0fc7b3852f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147342
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Ryan Macnak