Vyacheslav Egorov
a6a99dc45f
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>
A package used to spawn the Dart Developer Service (DDS), which is used to communicate with a Dart VM Service instance and provide extended functionality to the core VM Service Protocol.
Functionality
Existing VM Service clients can issue both HTTP, websocket, and SSE requests to a running DDS instance as if it were an instance of the VM Service itself. If a request corresponds to an RPC defined in the VM Service Protocol, DDS will forward the request and return the response from the VM Service. Requests corresponding to an RPC defined in the DDS Protocol will be handled directly by the DDS instance.
SSE Support
For certain web clients it may be preferable or required to communicate with DDS using server-sent events (SSE). DDS has an SSE handler listening for requests on /$debugHandler.
SSE and package:vm_service example
import 'package:sse/sse.dart';
import 'package:vm_service/vm_service.dart';
void main() {
// Establish connection with DDS using SSE.
final ddsChannel = SseClient('${ddsUri}\$debugHandler');
// Wait for ddsChannel to be established
await ddsChannel.onOpen.first;
// Initialize VmService using the sink and stream from ddsChannel.
final vmService = VmService(
ddsChannel.stream,
(e) => ddsChannel.sink.add(e),
);
// You're ready to query DDS and the VM service!
print(await vmService.getVersion());
}