debug: supports disconnect/restart while program is running

[hyangah]

How to reproduce:

simple program

package main
import "time"
func main() {
   time.Sleep(1*time.Hour)
}

Launch debugging (F5) with "debugAdapter": "dlv-dap" in launch.json

While the program is sleeping, restart debugging (⇧⌘F5 on mac). See the previous debug session is terminated but the new debug session doesn't start. (Sometimes I get connection refused error popup but not always)

[hyangah]

This happens only when the debugged program is "RUNNING". If we set a breakpoint, the restart triggers a 'disconnect' command first to the debug adapter before restarting.
The main issue is that dlv dap is not yet able to accept additional requests while the program is RUNNING and the handler is blocked. I guess @polinasok is already working on the related issue.

Another issue is that, after sending the disconnect request, VSCode calls debug adapter descriptor factory's createDebugAdapterDescriptor again, with the exact same DebugSession object. This call happens before it receives the disconnect response. I don't know if that's a bug or an intended behavior yet. But the DebugSession object passed here was modified during the previous call (i.e. we set 'port' attribute), and as a result, VSCode tries to contact the same dlv dap server using the port. As a result - if dlv dap is dead somehow, restart will fail with the connection refused error. If dlv dap is alive still stuck working for the previous run, VSCode will stuck in the DebugAdapterServer waiting for the dlv dap to answer.

The first step is to fix the delve to accept more requests.

cc/ @suzmue @polinasok

[polinasok]

That's right: disconnecting while running is blocked on async support that is work in progress.

It is odd that vscode doesn't wait for disconnect response before calling the factory code again to relaunch. According to the DAP spec, a client should "implement 'restart' by terminating and relaunching the adapter", which to me implies actually waiting for the indication that the adapter terminated (aka disconnect response). If that is not the case, I would file a bug against vscode.

In any case, when the factory starts up a new server, I think it should always use a new port. Even if our code times everything right, we are still at the mercy of the OS. The port might take a moment to free up. This actually reminds me of microsoft/debug-adapter-protocol#126.

Does vscode set restart in DisconnectArguments?

[hyangah]

Thanks @polinasok

It is odd that vscode doesn't wait for disconnect response before calling the factory code again to relaunch.

Unsurprisingly, there is a timeout. Since dlv dap didn't respond timely, VS Code went ahead, continued remaining cleanup tasks (socket close, adapter dispose, ...), and restarted.

According to the DAP spec, a client should "implement 'restart' by terminating and relaunching the adapter", which to me implies actually waiting for the indication that the adapter terminated (aka disconnect response). If that is not the case, I would file a bug against vscode.

I think the timeout from the client side is a reasonable defense mechanism in this case.

In any case, when the factory starts up a new server, I think it should always use a new port.

Yes, I will prepare a fix.

Does vscode set restart in DisconnectArguments?

Yes.

[gopherbot]

Change https://golang.org/cl/305552 mentions this issue: src/goDebugFactory: don't modify DebugConfiguration.port

[polinasok]

Both disconnect and restart for me now.

[hyangah]

Thanks @polinasok.