-
Notifications
You must be signed in to change notification settings - Fork 324
Breakpoint not hit on web after a hot reload in latest stable #5211
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
Comments
Did you mean hot restart by any chance? |
Nope, hot reload :-) |
Wait, I kinda do, because we don't support really hot reload on web. But as far as the IDE knows it's a hot reload 😄 (see #4991) (but if I send a Hot Restart from the IDE, all is fine... if I send a Hot Reload, then we don't seem to see get the pause) |
That's interesting that hot reload doesn't work while hot restart does since they should be doing the same thing at this point in time on stable... |
I'm not sure what might have regressed here, but here is the tracking bug for initially getting this to work: flutter/devtools#7231 Sending you both a doc with more details as well |
Hmm, interestingly with a brand new project I see this bug on both stable and beta, but on the Dart-Code test project (which is basically the same but with a little extra code that sets some variables and prints some values), it works on stable but fails on beta. I wonder if there is a race here and the test project has enough code that affects the outcome. Testing on the version where I see the difference, the logs look like this. For stable (when it works), the VM service traffic when I hot reload looks like this:
Here, a breakpoint is added and then the isolate is resumed. Note: This traffic is all from the VM Service (DWDS), nothing was sent to it. I think this means DWDS is sending the breakpoint and resuming (this is unexpected, but presumably what results in the breakpoint working). In the broken version (beta), the log looks like this:
Here, the isolate is resumed, but no breakpoint was added. I think this may be related to the issue @elliette linked above, because we don't think DWDS should be adding the breakpoints (the IDE/DAP should). However, the isolate being resumed before DAP has been able to re-send the breakpoints means there is a race here. The isolate should be starting paused. Looking back through the complete log, I see this:
This |
I was going off the assumption that It looks like DWDS 24.0.0 is in the current Flutter beta: https://github.com/flutter/flutter/blob/7c6b7e9ca485f7eaaed913c6bb50f4be6da47e30/packages/flutter_tools/pubspec.yaml#L17 There were some fixes to restarting with breakpoints in DWDS 24.1.0, although I'm not sure they would fix this issue. https://github.com/dart-lang/webdev/releases/tag/dwds-v24.1.0. That version is on Flutter master though https://github.com/flutter/flutter/blob/cdab9d509b79660164791c34fb6e2610c7233ae8/packages/flutter_tools/pubspec.yaml#L17, so it might be good to see if this reproduces there or not. I think regardless it might make sense cherry-picking 24.1.0 into the current Flutter beta, so that it has dart-lang/webdev#2441. FYI @bkonyi |
That makes some sense to me, but isn't DDS handling the pause/resume behaviour, so if it treats it as a hot reload (since that's what the DAP is sending), wouldn't it use the reload flag? (and could that be why it's immediately resuming, since we didn't set that?) If it's not that, I'm still wondering if we have a bug for non-web here - we're never setting I re-tested on Flutter master, but no change there, same issue. |
Thinking more, I think this is only an issue if there's another debugger also trying to resume (which won't wait for DAP). So if I'm understanding correctly, I think there is a bug there, but it's probably a minor one few will see (requires two debuggers)? I also don't think it's related to the issue here for the same reason, because there are not two debuggers involved. I think the main issue here is that during a "hot reload", there is no pause, so the breakpoints race with the application starting to run. |
Not sure where this bug is yet, but on current stable if I:
The breakpoint is again hit during the execution of code after the hot reload.
However, on the latest beta, the breakpoint is hit the first time, but is not hit after the reload. A quick scan of the logs suggest that the VM does not pause during the hot reload.
This is causing the "stops at a breakpoint after each reload (1)" integration test to fail.
(@elliette @bkonyi FYI in case you have any ideas, it might take me a little while to get useful logs that can be compared since there's a ton of noise in them)
The text was updated successfully, but these errors were encountered: