debug: toggling breakpoints hangs while focus is on an ephemeral goroutine #1648
Comments
|
I'd give you more logging info - but I've always found selecting text & copying from output to be nigh-impossible (linux mint / cinnamon vm, if that matters). |
|
Note: I was informed that using dlv-dap the behavior of setting a BP causes the process to be paused. Simply resuming the process after setting the BP does appear to work. |
|
Hmm... having that "jumps to runtime/sema.go" over and over bug (similar to #1617). I simply set a BP - started a session - after it trapped into debugger - stepped a few lines, then stepped into something - and it began happening on each new step... |
|
@lucky-wolf Seems like you already figured out how to handle the original issue - resuming after changing breakpoints - and now you are experiencing a different issue - jumping to Re: #1648 (comment) |
hyangah
added
Debug
hyangah
changed the title
|
@hyangah apologies for the swerve - but yes, I was asked on #1648 to start another report for the toggling BP issues - but for the most part those are just not automatic anymore - if I manually resume the debug process after toggling one, it does appear to work as expected. So that could be said to be "working as intended" However, while using the debugger yesterday - I did run into essentially that same bug (well, nearly same behavior, if the same cause or simply something like it) - where each step over / step into would flash over to a go runtime file - seemingly to do with goroutine state assessment? in 1648 it was a different file - this time it jumps into sema.go. there's a lot of context switching in the debug output from dlv-dap - but nothing more interesting than that. screenshots might be easier than copying the text from the debug output window - not sure why that is so user-unfriendly - but I cannot find a good way to simply select multiple lines & copy them out - it refuses to allow me to select them properly and becomes impossible to interface to when I do have a selection... |
Setting breakpoints while the program is runningJust to confirm the expected behavior (which you already seem to have figured out):
Jumping goroutines/files while steppingThis is likely caused by the same underlying issues as #1617 and #1647. Since everybody's goroutine set up iss differemt, it is not surprising that flickering files are not always the same. We have submitted an additional fixes for the issue since it was reported, so please do make sure that you are using the most recent version of dlv-dap. Coping logsYou should be able to right click on the Debug Console and choose |
|
@polinasok thanks for the feedback! Similarly, if I could drag above / below the current window so it scrolled while selecting - that'd be useful. But neither of those exist, so selecting a chunk is nigh-impossible. All will work (and I can edit that in another text editor after that). Any improvements to make the setting of a BP during "running" state auto-resume would be nice. Messaging me to say "app paused to set new BP - press continue to resume..." would be helpful. Thanks. |
|
Since I've got a platform to make some comments, I'll add one more: It would be nice if the dlv-dap captured the remaining debug output once I hit "stop". I think you disconnect before the app is actually shut down? So any final log output is missed from the debug console. That or dlv-dap still only kills dlv and fails to send a stop interrupt to the underlying debug process? My graceful shutdown code (which triggers on such an interrupt) is not visible in the debug console, but I am certain works if I send a stop from some other mechanism (e.g. a rest call that issues it against itself). Preferrable to have dlv-dap send a terminate / stop interrupt rather than just hard killing the process immediately. Or for that to be a configurable option anyway (in the launch settings + user + project defaults?) |
|
@lucky-wolf you can access equivalent tracing info from "Go Debug" output channel which in my opinion is a bit easier to select/copy/paste than the Debug Console where various javascript runs because it's primarily targeted for repl use.
Triaging and inspecting the issue will be much easier if you can share the trace/log.
For graceful shutdown, there is an open issue #120 I believe dlv-dap has the same issue. |
|
@lucky-wolf Just to add to what @hyangah wrote. The logging in Go Debug output channel is enabled with Then add Edit: recommend using debugServer to attach to debug server. |
|
Just to add about shutdown. Dlv-dap is supposed to shut down gracefully if it receives an explicit disconnect request from the editor or is killed with SIGTERM or SIGINT (which is what we do to force-kill it from the extension if the server becomes unresponsive). If target was launched, it should be taken down by default as well (unless you toggle the stop/disconnect option in the client to change the default). If you attached to an application, it should keep running (unless you toggle stop/disconnect option in the client to change the default). |
suzmue
added
the
WaitingForInfo
|
I'm facing same issue with uncheck The whole action chain: |
|
It is anoying whenever we place breakpoint during debug, it pause all debug instance. Please have a setting that do not pause on place breakpoint during debug (if it didn't trigger intemediately) |
|
@zzjin We either need a reproducible test case or a client-side log to see what requests the client processed to be able to diagnose this. Please also share if any warnings were printed to Debug Console.
At this point, whenever you make any changes to breakpoints (set or unset) while the process is running, we will pause and print a message to the Debug Console requesting that you continue manually. Do you see such a message? |
|
@oxycoder Thank you for your input, we realize that the behavior of pausing to set a breakpoint is unideal. Continuing automatically is work in progress. Thank you for your patience. |
|
Timed out in state WaitingForInfo. Closing. (I am just a bot, though. Please speak up if this is a mistake or you have the requested information.) |
|
The issue is not fixed. Reopening. |
hyangah
removed
the
WaitingForInfo
|
Which specific problem are we trying to address under this bug? We should rename the title to say so. Users are rightfully unhappy that we have to pause and request manual Continue when (un)setting breakpoints while the process is running. We also filed #1676 for that. But there are also reports of other odd behavior in here. For example @ |
|
Reproduceable minimal code with log:
package main
import (
"fmt"
"net/http"
)
func main() {
http.HandleFunc("/hello", func(w http.ResponseWriter, _ *http.Request) {
fmt.Fprint(w, "Hello, world!") // set breakline here.
})
http.ListenAndServe(":8080", nil)
}
{
"version": "0.2.0",
"configurations": [
{
"name": "Debug",
"type": "go",
"request": "launch",
"mode": "auto",
"program": "${workspaceFolder}",
"showLog": true,
"logOutput": "debugger,dap",
}
]
}
with debugger stopped at breakpoint as except.
|
hyangah
changed the title
|
Thanks @zzjin for the repro. @suzmue located a bug in VS Code that caused this misbehavior. She is following up the issue by reporting the issue upstream (microsoft/vscode#133623). My understanding is that the pause/continue button in the debug toolbox lost track of the debugger's state because the goroutine (the http handler goroutine in the example) that was on focus is gone after continue.
While we track the general UX improvement (i.e. auto-resume after changing breakpoints) in #1676, let's use this issue to track the specific issue around working with short-lived goroutines. EDIT: I am guessing the legacy debug adapter avoids this issue by always sending the current goroutine id in StoppedEvent. If there is no current goroutine, it also picks up the first goroutine from the goroutine list. |
hyangah
added
upstream-vscode
|
@suzmue Is it a possibility that dlv-dap returns a thread id with the stopped event to workaround this issue? |
|
If you're not aware this problem also exists when you do dual debugging under VS Code. One is running delve with the Go webservice, and another is using the Firefox debugger. Setting a breakpoint in Javascript then pauses the Go side of things, and you have to switch to the other session in the dropdown menu and press F5 to continue. So fixing this is very welcome :-) |
|
This should be fixed in the latest version of VS Code (verified with 1.63.0). If you are still experiencing this issue, please reopen. |
What did I doRecreated the test case that @zzjin posted on September 17, 2021 What did I expectSetting the breakpoint on line 10 would not cause execution to be suspended. What did I see insteadThe message "Execution halted to set breakpoints - please resume execution manually" appeared in the logs. The debugger was stopped and F5 was required to resume execution. Although @suzme said that this was fixed in VSCode 1.63.0, there may be a regression or another issue. Output logs:Version Information:go version go1.17.6 windows/amd64 go extension version: code -v gopls -v version dlv-dap version -v |
For asking questions, see:
#vscodechannel in Gophers SlackBefore filing an issue, please review our troubleshooting guides
Please answer these questions before submitting your issue. Thanks!
What version of Go, VS Code & VS Code Go extension are you using?
go versionto get version of Go from the VS Code integrated terminal.gopls -v versionto get version of Gopls from the VS Code integrated terminal.code -vorcode-insiders -vto get version of VS Code or VS Code Insiders.c3f126316369cd610563c75b1b1725e0679adfb3
x64
Go: Locate Configured Go Toolscommand.Share the Go related settings you have added/edited
Nothing very interesting...
Describe the bug
When I set a breakpoint in a running session using dlv-dap, the process hangs (assuming it wasn't paused when I set the BP).
When I clear a BP in a paused session using dlv-dap, I thrown into src/runtime/sigqueue.go:168
Eitherway - unable to change BPs in an active debug session. I can change them if I exit the process first, and start a new session.
Steps to reproduce the behavior:
launch a go server
to set a BP on something you know will trigger in a moment / after an action
do that action to trigger that code
nothing will ever happen (the process is frozen)
Screenshots or recordings
If applicable, add screenshots or recordings to help explain your problem.
The text was updated successfully, but these errors were encountered: