-
Notifications
You must be signed in to change notification settings - Fork 752
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
debug: setting breakpoints while stepping causes step to be skipped #787
Comments
Looks like our first problem is Our second issue is that delve doesn't seem to know it was in the middle of next when we issued a halt ( |
@aarzilli, is it normal that when next (that sleeps) is interrupted by halt, NextInProgress is not set to true nor returns an error? I think this can be more or less reproduced with Ctrl-C with dlv cli:
|
Halt was changed to automatically cancel any next operation in progress in march 2018 commit go-delve/delve@449b3ce to fix issue go-delve/delve#1145. |
Ah, thank you for clarification. @suzmue In that case, we can leave skipStopEventOnce the way it is, tracking if continue is in progress, and generate StoppedEvent('step') as we do now, but then instead of continuing in setBreakPointscallback, we can use an OutputEvent to print an error message to the debug console and also document this in our user docs. What do you think? |
Change https://golang.org/cl/261078 mentions this issue: |
…rrupted In order to set breakpoints, a running program must be halted. When a next, step in, or step out request is interrupted by a halt, the request is automatically cancelled. Unlike the case when continue is interrupted, we should not suppress a stop event and automatically continue. Instead we issue a stopped event and log a warning to stderr. Test that the debug adapter is able to set breakpoint requests while the program is running continue, next, and step out requests. Updates #787 Change-Id: I1b17a65d15fd35c628b1fa2d823c558a24a84727 Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/261078 Trust: Suzy Mueller <suzmue@golang.org> Run-TryBot: Suzy Mueller <suzmue@golang.org> TryBot-Result: kokoro <noreply+kokoro@google.com> Reviewed-by: Polina Sokolova <polina@google.com>
Change https://golang.org/cl/279416 mentions this issue: |
@suzmue @polinasok do you want to track changes for DelveDAP in a separate issue? |
This entire feature (setting breakpoints while the program is running whether on continue or step) is not yet implemented in the new adapter, so it might not make sense to file a separate issue for a bug in a feature that doesn't yet exist. When we work on the implementation, we will base it on the existing code and unittests and avoid the bug all-together. This brings us to a more general question of how to track not-yet-implemented features. Should we be filing issues for each one? In this repo or in the delve repo? Whether or not we file the issues, it would be ideal to have a set of vscode-go unittests corresponding to the features we want to support and then we can test the new adapter against that and know exactly what is missing. |
This has now been implemented in dlv-dap, with the same behavior. This is not an issue we plan to fix in either adapter. |
I believe the original issue in the old adapter was about using regular continue after setting a breakpoint and running to program completion, never pausing. Our fix was to not skip the stopped event (like we did with regular continue) and just report that next was automatically cancelled. We did not continue at all since we could not finish just the next operation. The dlv-dap adapter doesn't have the original problem. But it does cancel next if a breakpoint is set while it is running. |
The current behavior (delve goes bust when setting a breakpoint when the program is stopped) is absolutely annoying. Not being able to edit breakpoints without a full debug session restart causes excessive development overhead. |
Hi @cfiderer! The workflow that you are describing should be working using both the legacy adapter and dlv dap. If you are having a problem with this could you please file a separate issue? This particular issue was about the behavior when a user attempts to set a breakpoint while the program is running. |
@cfiderer: Please be conscious of your language and tone when commenting on this issue tracker. You can see the Go Code of Conduct to learn more about our community standards. |
Hello @suzmue, I'll try to pin the observed behavior down to a small case and open an issue then. |
@cfiderer, +1 to what @suzmue said. You should be able to set/clear/edit a breakpoint in the middle of a debug session without a restart. We currently have a legacy adapter and the experimental dlv-dap adapter. The behavior should be exactly the same for both when the program is stopped. When the program is running (either doing a continue or one of the step commands), the dlv-dap adapter will pause execution to set the breakpoint and let the user restart as needed. Please also note that when you change one breakpoint, all other breakpoints reflected in the as previously set UI should persist as well. Please do file an issue with steps to reproduce, screenshots, etc if any of this is causing troubles. |
Please answer these questions before submitting your issue. Thanks!
code -v
orcode-insiders -v
to get version of VS Code or VS Code InsidersDescribe the bug
If during a next request, you try to modify the breakpoint (by setting, deleting a breakpoint etc) the step function does not complete.
Steps to reproduce the behavior:
main.go
launch.json:
This issue is caused for two reasons:
The text was updated successfully, but these errors were encountered: