Pause command doesn't work #978
Comments
|
@ramya-rao-a is this an issue with the plugin or with vscode? |
|
I dont have a proper repro for this. Can you share a sample code with repro steps? cc @roblourens |
|
So here are the steps to reproduce:
Sample program package main
import (
"fmt"
"sync"
"time"
)
func main() {
wg := &sync.WaitGroup{}
wg.Add(1)
go func() {
for {
fmt.Println("I'll just take a nap for a second... ZZZzz....")
time.Sleep(time.Second)
}
}()
wg.Wait()
} |
|
Thanks for the steps @renannprado cc @roblourens |
|
When debugging starts, vscode sends a ThreadsRequest. goDebug.ts sends a ListGoroutines request to Delve, but Delve never responds. So then when you click Pause, vscode doesn't know which thread to pause, and never sends the pause request over. I suppose we need to figure out whether we're caling ListGoroutines at a bad time, whether it's a Delve bug, or if we should just add a timeout for it. |
|
And as for setting the bp after launch, I don't know whether it should be possible to set a BP when Go is in a loop like that. I can't do it with Delve at least. |
|
@roblourens yes, it is possible (will later update with an asciinema session to show) |
|
Hi, I searched why I cannot set breakpoints as verified in VSCode while the program is running (after continue) and found out that you cannot set breakpoints in delve until you stop/halt debuggee program via delve. That is, if you try to set a breakpoint in vscode while the debuggee program runs, the request to delve CreateBreakpoint hangs forever (till debugging session' end) and even F6 (Pause) will not work. So I suggest to make start/stop requests to delve for every breakpoint being set if debuggee is running. That is, to call pauseRequest()/continueRequest() in setBreakPointsRequest() , see at https://github.com/Microsoft/vscode-go/blob/master/src/debugAdapter/goDebug.ts#L530 I've checked out Goland, https://www.jetbrains.com/go/ , and found out that they do just stop/start in such situations. Here is the log from delve (patched by me) under Goland control, showing that delve was started and stopped only for setting breakpoint: Also, I've checked https://github.com/derekparker/delve sources and found out why one should not request CreateBreakpoint command while debuggee is working: every command except halt (= Pause in vscode) try to lock See at https://github.com/derekparker/delve/blob/master/service/debugger/debugger.go#L284 |
|
I am not so good with TypeScript and those promises so I cannot make PR for my suggestion myself, the right way. Please help me with that. |
|
@muravjov Thanks for the investigation!
This would work assuming that |
|
Yes, I am if I do it in right order: at first pause the program, then set breakpoints. |
|
I am not able to pause to begin with. Can you share the program you are using? I was using the |
|
Yes, I checked both examples, https://github.com/golang/example/tree/master/outyet , and #978 (comment) , and the situation is the same, vscode-go' delve controller stops to send any command to delve. At the start of debug session vscode-go calls two GoDebugSession' methods, continueRequest() and threadsRequest(), you may see it in Debug Console, ContinueRequest and ThreadsRequest correspondingly (with "trace": "verbose" in launch.json). In the majority of cases ContinueRequest occurs earlier, and delve's command "continue" lockes processMutex' mutex, see above. The next ThreadsRequest never returns , so no next commands, including Pause, ever has chance to be invoked. Fail. You may see that ThreadsRequest is locked by killing dlv with SIGABRT signal so it prints its tracktraces: Sample stacktraces of killed dlv: Here we see that goroutine 34 is locked by processMutex - debugger.go:825 in (d *Debugger) Goroutines() - it is our ThreadsRequest . And goroutine goroutine 25 that locked processMutex - it is our ContinueRequest . But there is another situation there, when ThreadsRequest is invoked earlier than ContinueRequest . In that case delve returns but again, for some reason, I still don't see ThreadsResponse. Thereby Pause/pauseRequest() is not working again (whereas button Stop/disconnectRequest() works, sending 'halt' command successfully). If I have time later I'll debug vscode-go and can say why it is. So, workaround is simple now: always set a breakpoint and when control hits it deadlock is over. |
I can see this happening when I try to pause a running program which never had any breakpoints If I have a breakpoint, it gets hit, I continue, and then after a while try to pause, then I see the
How do we determine when the deadlock is hit? Also, we cannot set breakpoints when the program is running, we have to pause/halt it. |
From the delve's side you are to find out whate all goroutines are doing now = their stacktraces. On Linux and MacOs you may kill go program with signal SIGABRT with the same effect, rebuild is not needed. |
|
Is there any workaround for the Pause -> set breakpoint -> Continue issue? I'm running vsc 1.22.2 with go extension 0.6.78 and still hitting the issue: everything goes fine until I "Pause", then I can set a breakpoint (breakpoint is "verified" it seems) but then "Continue" does nothing and the program doesn't keep running. |
|
same issue here. I have identified the following
|
|
Hi, For me, finally it allows setting new breakpoints while debugee is running. |
|
The Pause feature now works in the latest update to the Go extension (0.9.0) |
After starting a debug session, if you hit pause button, nothing happens.
This is important if you want to add breakpoints after running the application.
I was debugging the plugin and saw that
pauseRequestwas never called. So I wonder whether this is a bug in this plugin or in the whole vscode.The text was updated successfully, but these errors were encountered: