When starting flutter with DAP it fails to pause thread #57006
Labels
area-tools
A meta category for issues that should be addressed by tooling (prefer more concrete areas).
type-bug
Incorrect behavior (everything from a crash to more subtle misbehavior)
Comments
|
Summary: The Dart Debug Adapter (DAP) fails to pause threads when starting a Flutter app in the new 3.24 version. The DAP sometimes stops at random locations in the framework code or shows an error indicating that Thread 1 is not paused. |
dart-github-bot
added
area-vm
|
//cc @DanTup |
a-siva
added
area-tools
|
Although this may seem odd, this is working as expected. When the VM starts, the isolate is always started paused because we need to configure things like pause-on-exception, breakpoints, etc before any code is executed. This results in a When the debug adapter has finishing configuring the isolate, we will tell the VM we are happy for it to resume. Whether it resumes immediately depends on the whether there was also a user provided flag to start-paused, or any other connected debugger requested pause-on-start (so it can also send breakpoints etc.). If there are no other debuggers/user waiting, the isolate will be resumed immediately and otherwise it will remain paused until the other parties are done. When it resumes (which happens immediately in the case of the log above), we send a Now, it's very possible (even likely) that after the In earlier versions of DAP, we tried to hide some of the pause events from clients (for example the pause-on-entry) to make the traffic simpler, however the changes to support multiple debuggers and honour user-supplied pause flags means we can't be sure if our request to resume will actually resume, and therefore if we didn't send pause-on-entry, the client would not know that the isolate is still paused. Therefore, my expectation is that DAP clients will gracefully handle failures to requests like |
|
Thanks for the explanation, @DanTup. Yes, it looks like retrieving the stacktrace on the |
This makes sense - VS Code does the same.
That behaviour only works if we assume this DAP client is the only possible thing that can cause the VM to control pause-at-startup and pause/unpause during debugging. That assumption was never truem although we had other issues that made it difficult to have multiple debuggers attached. We've solved those issues (with IMO your DAP client needs to not treat this condition as an error and instead as something that can happen in normal operation (probably by silently handling the unsuccessful request and assuming that the thread is no longer paused/valid). If they are uncomfortable with that (because the spec doesn't say a lot about this), we could file an issue in the DAP tracker and try to agree something about this in the spec so all clients/servers can be sure they're on the same page. |
|
In your explanation, you mentioned that the race is happening between DAP log |
In the DAP log above, there is also a So this seems like the same thing - this is the VM pausing at start, but then being resumed once the configuration is completed. If your editor continues to show that execution is paused on that line, that seems like a bug. I'm not sure why you see different stack locations though - I've not been able to reproduce that yet. In VS Code, the |
|
I added some delay in the debug adapter implementation to force the stackTrace request to complete in VS Code, however the stack I get back from the VM is empty in this case: This makes me wonder if there are differences in our apps, or the platforms we're running on that might affect this. Can you confirm whether the non-empty stack when paused-at-startup occurs in a new |
|
I am running flutter app in Android simulator in macOS. DAP log 1 |
DAP log 2 |
DAP log 3 |
|
In log 1 and log 2 debugger tried to stop at some invalid location, in log 3 I got "Thread 1 is not paused" error.
Can you give me more details about how the non-user code is identified? |
|
@sidlatau thanks for the logs - I will try to dig through them soon.
There are flags If you set these to |
|
Hmm, I added DAP log 4
Frames:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With new 3.24 flutter version DAP shows error when starting an app. No breakpoints are set manually, but it tries to stop. Sometimes it stops at some random spot in framework code, sometimes it shows error "Thread 1 is not paused".
There is related issue registered in nvim-flutter/flutter-tools.nvim#402
which may provide additional details.
Client: neovim
Code to reproduce: for me the problem occurs in every repository, I tested with this one: https://github.com/sidlatau/flutter_email_sender/tree/master/example
Flutter doctor output
DAP log
The text was updated successfully, but these errors were encountered: