-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failures on [dds/dap] Don't sent breakpoint changed events until after the response to setBreakpoints....[cfe] Update test expectation #51928
Comments
Can't see anything obviously wrong. Is this failing only on Linux, and 100% of the time? Will try and get a Linux container set up and see if I can repro locally to debug. |
Yes, consistently failing on https://ci.chromium.org/p/dart/g/be/console?limit=200 under pkg -> dl (now it's green because I approved the failing test with a reference to this issue). The first red was your commit. |
Thanks! I'm struggling to reproduce this in an Ubuntu container in Docker. I'm using an SDK checkout at e1c2192 with a pre-built bleeding edge SDK: Dart SDK version: 3.0.0-edge.8d16c1dc871a42bb4f643d7c29a17148f0228935 (be) (Mon Apr 3 15:04:07 2023 +0000) on "linux_x64" And I'm running the script like:
But everything is passing (and fairly quickly):
I tried running the version from the built SDK, as well as running the tests with an in-process debug adapter, and from source out-of-process And using the python script:
@dcharkes do you know anything more about the environment that might help me reproduce? Do the tests run in some container I can use directly? And do you know what the timeout is? I'm not sure how to interpret the results.. the top of the results say "command VM took 16 minutes(?)" and then print a bunch of stacks, but this comes before any test output. Did this actually occur after the tests started (eg. it's some diagnostics trying to capture VM stacks after the tests took too long), and not something that occurred prior to the tests running? |
This locally makes the test timeout for me:
The test seems to recognize it's stuck:
On commit: d758cf1
Yeah the stack traces are just the VM being killed because the test time out. The question is why the Dart code does not finish. If I skip test('responds to setBreakpoints before any breakpoint events', () async { the suite doesn't freeze. |
Thanks - I'll try this out later. I would've thought using the pre-built SDK should behave the same, but maybe there's something different. Out of interest, what OS/distro are you using, so if I can't repro with Ubuntu I can try that? btw, if you have a spare minute and still have this set up, running with Thanks! |
|
@dcharkes thanks! I'm still wrestling with setting it up locally, however I see what seems like a crash in your log:
@bkonyi I suspect this isn't related to my change, but perhaps my change is causing it. It seems to happen around the time I try to add breakpoints to lines 1-50 of a file (a file which doesn't actually have 50 lines). I don't know why it would only occur on Linux (or why I can't repro locally yet). Is there enough info here to understand what's wrong? Edit: Maybe using a prebuilt SDK doesn't have the asserts enabled, and once I've got this one building locally I'll see the same? In which case, perhaps it'll repro on mac too.... Testing it out. |
Got a change open at https://dart-review.googlesource.com/c/sdk/+/292784 that will print all This doesn't solve the issue, I'll wait to here what @bkonyi thinks about the assertion failure ( |
…s to help catch VM crashes See #51928. Change-Id: I32edbae5433d003ca0295d95fc834b8cd3b8fa5e Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292784 Commit-Queue: Ben Konyi <bkonyi@google.com> Reviewed-by: Ben Konyi <bkonyi@google.com>
I've opened https://dart-review.googlesource.com/c/sdk/+/310880 to tweak this test so the lines are not invalid, but I think should fix this. The underlying issue (causing the assertion failure) should be handled via #51951. |
There are new test failures on [dds/dap] Don't sent breakpoint changed events until after the response to setBreakpoints....[cfe] Update test expectation.
The tests
are failing on configurations
log
The only commit in that range related to DDS is:
Which happens to add that test.
cc @DanTup could you please take a look if this test is still doing the right thing after your change?
The text was updated successfully, but these errors were encountered: