debug: dlv dap remote debugging does not start anymore

[debevv]

Hi, in this comment of another issue #1647 (comment) I managed to create a correct configuration for remote debugging with delve DAP on a ARM system.
The configuration worked correctly for a while, but lately It stopped doing so.
Specifically, after running the configuration I see vscode opening a TCP connection to the dlv server on the remote machine, but then not sending any additional packet. On the ui i see the debugging commands panel appear, and the blue progress bar spinning forever.
I tried to enable verbose logging on both sides, but with no result.

Were some changes made that should be reflected in my conf?

[hyangah]

@debevv Remote debugging support is still a work in progress. As the dlv-dap graduates from its experimental stage, we removed the preliminary host/port support, and asked to utilize the debugServer option or the legacy mode debugging instead. https://github.com/golang/vscode-go/blob/master/docs/debugging.md#remote-debugging

In your case, you need to connect the debug server running on a different host, right? Unfortunately, debugServer does not support that's not yet supported. A good news is the issue #1647 was fixed in the legacy adapter. Let us know if switching back to the legacy mode is an option. Otherwise, we will consider adding a temporary workaround for you until Delve DAP's remote debugging support is ready. Sorry for the inconvenience.

[debevv]

Thanks for your response. It's a pity because it used to work very well.
It's not a problem for me switching back to the legacy adapter for a while anyway.
But from what I saw the adapter it's actually still following the host/port combination in some way, because I can see it connecting to the remote host following these values. Add to it the fact that the support was already in place, it would be nice for me to have the functionality back, since it doesn't look like a lot of effort (at least until it will work the same via debugServer)

[debevv]

@hyangah I tried going back to the legacy adapter, but I quickly dismissed it since I never found a decent way to integrate it seamlessly with vsocde in my use case (lots of scripting and babysitting because dap must be started at every debugging session etc.). That proc.go issue is gone btw.

Anyway, I found a nice workaround for remote debugging with DAP. Since the adapter can now connect only to localhost, i created an SSH port forwarding to my embedded device, like this:

ssh -L 12345:localhost:12345 <my device address>

and set debugServer to 12345

I'm ok for now, but in the future It would be nice to have the possibility to specify the host address again.

[hyangah]

Thanks for understanding and working around the issue @debevv.
We will try to fix it soon.

I noticed that your use case is a bit different from the use case we've focused on (i.e. attach+remote). The logic that we hoped to prevent use of Delve DAP for remote debugging failed to capture the case early.

{
    "name": "Connect to server (DAP)",
    "type": "go",
    "request": "launch",
    "debugAdapter": "dlv-dap",
    "port": 12345,
    "host": "192.168.1.26",
    "mode": "exec",
    "program": "/usr/bin/repr",
}

@suzmue I think if the debugAdapter was explicitly set to dlv-dap, we can still support the use of host:port in this case. What do you think?

@debevv This is an interesting use case and I want to understand better. You said:

a lot of scripting and babysitting because dap must be started at every debugging session.

How did you handle it when you used the legacy debug adapter? I thought you had to restart the headless dlv exec on the remote machine every time or somehow made the headless server 'restart' the debugee. Wasn't it true?

[debevv]

@hyangah with the legacy adapter I use this configuration:

{
    "name": "repr legacy remote",
    "type": "go",
    "request": "attach",
    "mode": "remote",
    "remotePath": "",
    "port": 2345,
    "host": "192.168.1.26",
    "cwd": "${workspaceFolder}",
    "preLaunchTask": "delve-legacy",
}

The delve-legacy prelaunchTask basically executes dlv on the remote machine like this:

dlv --headless --listen=:2345 --api-version=2 --log exec /usr/bin/repr

Along with other tasks' settings I managed to create a somehow acceptable, but very brittle, setup. One of the problems is that console management is very shaky, sometimes i don't get the application log, or it doesn't show automatically etc.

On the other hand, with DAP i just start delve on the remote machine at the beginning of my work day:

while true; do dlv dap --listen=0.0.0.0:12345; sleep 1; done

I use a while loop because delve exits when the program being debugged is terminated.

And use this config (new one, with SSH port forwarding):

{
    "name": "repr DAP remote",
    "type": "go",
    "request": "launch",
    "debugAdapter": "dlv-dap",
    "debugServer": 12345,
    "mode": "exec",
    "program": "/usr/bin/repr",
}

(I omitted from both configurations the preLaunchTask I use to build and copy the program on the remote device before debugging)

You may be asking: why don't I use the while true loop with delve legacy too (avoiding starting it every time)? The answer is that with DAP i actually start and stop the program, with legacy instead I'm merely attaching and detaching to it. Consequently, when i detach from the debugging sessions, the program doesn't stop, and this is a problem.
I know I may sound spoiled, but a flawless edit-compile-run cycle is very important to me, and i found DAP much less frustrating from this point of view.

I hope i answered your question. Otherwise i can send you all the script files involved in my dev setup

[suzmue]

Thanks for sharing your use case! We plan to add back in support for this as soon as we can.

[gopherbot]

Change https://golang.org/cl/346269 mentions this issue: Revert "src/goDebugFactory.ts: direct users to use 'debugServer' for remote"

[polinasok]

@debevv I am glad to hear about this use case as well! Thank you for explaining. We were going back and force on whether this new version had its own merits (as opposed to the legacy configuration, which we also plan to support with dlv-dap), and this issue is giving us a much needed insight into how people use these configurations.

[gopherbot]

Change https://golang.org/cl/346270 mentions this issue: src/goDebugConfiguration: show warning that port is being used

[debevv]

@polinasok you are welcome, my only gripe was the recent removal of the host parameter that assumed the delve to be always on the same machine
Apart from that, i think you guys are doing great with the new DAP adapter, personally I wouldn't change anything else

[hyangah]

The fix should be available in the Go Nightly. @debevv We plan to release a new version with Suzy's fix near future, but if possible, can you try the Nightly and see if it has everything you need? Thanks!

[hyangah]

The fix is now picked up for v0.28.0 RC. Closing.

[gopherbot]

Change https://golang.org/cl/352056 mentions this issue: [release] src/goDebugConfiguration: pick fix for #1729