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>
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>
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>
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>
This test shows up as flaky quite often. It's waiting for breakpoint Resolved events by just calling `await pumpEventQueue(times: 5000);` but it appears this sometimes doesn't get all of the events.
This change waits up to 5s for the events to arrive (because we unfortunately have no signal to know when they should have come through). I'm hopeful 5s is more than enough and this won't flake, but we could increase this as not - the goal of this test is not to verify performance but just ensure the events do arrive.
Change-Id: Ia2236b65bbb5d11e2a5519d49869c6b87202a940
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/367301
Reviewed-by: Helin Shiah <helinx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Sometimes we see unhandled exceptions during this setup work, see:
- https://github.com/flutter/flutter/issues/148346
- https://github.com/flutter/flutter/issues/148348
Currently these are unhandled and bring the debug adapter down. In VS Code, the error (send to stderr) is not visible to the user so they just see a silent crash which makes it very difficult to report (and the Flutter crash reports don't have any context).
This change will send the exception to the client and then cleanly terminate, which should give the user more information to open a good bug report (assuming the issue wasn't just something like them terminating the app as it was starting).
Change-Id: I4aefbc278e6a0708924c6fa41c5179d581117689
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366662
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
In a recent change I wrapped these exceptions to provide better failure messages in tests, but I missed updating these tests that had matchers against them.
For reasons I don't yet understand, the trybots that ran on that change didn't include these tests so didn't catch this.
Change-Id: I5227842d2317bbe33186670141586c315f98a5c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366665
Reviewed-by: Helin Shiah <helinx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Helin Shiah <helinx@google.com>
getObject and invoke would `throw` if the response was a sentinel and that wasn't handled correctly, which meant sometimes an entire variables request would fail instead of only the individual values (eg. in a map/list) being shown as erroring.
This improves https://github.com/dart-lang/sdk/issues/54897 (you'll no longer see the entire request fail), but it still needs paging adding too.
Change-Id: Ic3ed3bee7c1dd647ebae843007bd30b0e1fda590
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/364860
Reviewed-by: Helin Shiah <helinx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Breakpoint IDs were used in a few places here assuming they were globally unique, however they are per-isolate. If all isolates were given the same breakpoints this would work out fine, but when isolates were created/destroyed (eg. during hot reload) we could end up sending back the wrong resolution info to the client, resulting in breakpoints jumping to other locations (even though they were actually set in the correct locations).
Fixes at least some of the issues noted in https://github.com/dart-lang/sdk/issues/55268
Change-Id: I7acf93b99885c87ee0edd9ac1876f895c8943c51
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/365041
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
Commit-Queue: Helin Shiah <helinx@google.com>
Generally we don't untrucate values in the debugger in places where there might be lots of data (such as calling `toString()` on all variables) because it can cause performance issues if the variables are huge.
If you use the "Copy value" ("clipboard") or Debug Console evaluation ("repl") we _do_ always untruncate the values.
However, this code was always untruncating when we called `toString()` on custom classes. This changes it to no longer do so, making long string values consistent between what you see as the values of fields, and the `toString()` results against a class.
Fixes https://github.com/Dart-Code/Dart-Code/issues/4986
Change-Id: Ica3c5ecfed9492ab76fbfa83d161765b3b24eb22
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/363320
Reviewed-by: Helin Shiah <helinx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Helin Shiah <helinx@google.com>
The legacy debug adapters would scan all output for stack frames but when building the new adapters I only parsed stderr (because the stack frame parsing captures quite a lot and it seemed unnecessary). It turned out many users appreciated the IDE linking up stack traces in stdout too (because their exception logging framework may handle exceptions and print them this way, or they might have helpers to print the current stack trace to aid debugging).
This marks `parseStackFrames` as deprecated from `sendOutput` and scans all output for frames, while filtering out things that don't look like Dart URIs before calling `lookupResolvedUris` to try and avoid making general output async/slow.
If Flutter considers deprecations a bot failure, this will need to be rolled in manually.
Fixes https://github.com/Dart-Code/Dart-Code/issues/5072
Change-Id: I8857281fb79ca69328074d6ad6a0c0a505e5c193
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/362804
Reviewed-by: Helin Shiah <helinx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Helin Shiah <helinx@google.com>
The move to URIs introduced a subtle bug here - we would use the mapped URI (which is almost always `file:`) to decide whether to show a file path, instead of doing it only if the unmapped URI was a `file` (eg. it could have been `package:` or `dart:`.
This wasn't caught by any tests here, but was caught in the Flutter roll (https://github.com/flutter/flutter/pull/145235). This fixes it and adds a new test that we verify the Source names for local files, packages, and dart: URIs.
Change-Id: I282bf935b9fa4016abeafd556dfd368950ee9611
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/357325
Commit-Queue: Helin Shiah <helinx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
The VM service may now give us `dart-macro+package:` URIs in addition to normal `package:` URIs. These can be mapped to `dart-macro+file:` URIs in the same way that we map `package:` to `file:`.
If the client editor has advertised that they support our custom Dart URIs, we can send these through to the client and let them use the analyzer-provided local sources. Otherwise, we'll treat them like other unknown sources and download them from the VM.
Change-Id: If67523a615c66c469db7b1f52d281c63241eb859
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/357143
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
With the previous change, macro-generated sources will be downloaded from the VM the same as other sources we cannot map locally (which used to include SDK sources, but since we now map them to the local SDK, was currently nothing - hence the previously-skipped tests).
This just adds a test for this behaviour. In future when we have "full" macro support, this path will still be valid because some DAP clients might not support URIs as "source paths", and we will have to handle them with downloaded source anyway (we might also use this in future if we detect when the sources are different and download from the VM in that case).
Change-Id: Ib3289f9fe8396f3610d51fedd16d831b587afd04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354027
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
This test is to check the output contains "Detached" but didn't account for "Hello" appearing based on timing (during detach, we resume the isolate and depending on timing, we may or may not get the OutputEvent for the `print` in the test application).
This change switches from `emits` to `emitsThrough` so that the "Hello" event is ignored rather than a failure.
Fixes https://github.com/dart-lang/sdk/issues/53721
Change-Id: Ie624ba06e9f70dcbc887b2c280a3d2eb19dee29c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/348162
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
The initial global evaluation support only worked when the open script was loaded into the VM as a `file:///` URI (eg. things in a `bin/` folder, and not a `lib/` folder). This is because we short-cut resolving file paths to `package:` URIs for most VM functionality (for example setting breakpoints) because it's unnecessary (the VM supports setting breakpoints with file:/// URIs even for `lib/`).
This change forces us to resolve paths to their resolved URIs (eg. `package:` where applicable) in the case where we're looking up a script for global evaluation.
We could enable this lookup for all cases (to remove the additional `force` flag here), but since it's called much more from the other path (breakpoints) we should add caching (which was more than I wanted to change for this fix).
Fixes https://github.com/Dart-Code/Dart-Code/issues/4932
Change-Id: I57a99ec3b7c726d9d120e6cda7d0b938fec397bb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/346400
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Helin Shiah <helinx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
I noticed a race while running from source today.. If you run a Dart CLI app we add --pause-isolates-on-exit to allow sending async output events before exiting, then we resume.
The stopped event is still propagated to the client (since there can be a delay between the stop and the resume while we wait for output events) and the client may ask for a StackTrace. If this arrives just after we resume the isolate, we would generate an error that could be shown to the user.
This adds a check that the thread ID is really invalid before throwing an error, and if it's valid (eg. it belongs to an earlier isolate) we just return an empty stack trace instead of an error.
Fixes https://github.com/Dart-Code/Dart-Code/issues/4907
Change-Id: I0a3241ffd634acea49b4d1dc7b3cd6b6b1c8d2d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/342585
Reviewed-by: Helin Shiah <helinx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Danny Tuppeny