Skip to content

debug: shifts focus to proc.go when stepping to next line during remote debugging #1647

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

Closed
debevv opened this issue Jul 25, 2021 · 5 comments
Assignees
Labels
debug/legacy legacy debug adapter related issues - new issues won't be fixed Debug Issues related to the debugging functionality of the extension. Duplicate Make it obvious when issues are closed as duplicate FrozenDueToAge
Milestone

Comments

@debevv
Copy link

debevv commented Jul 25, 2021

Hi, I was redirected here after posting the issue on the vscode repository (microsoft/vscode#129356)

I'm experiencing the same problem explained in issue microsoft/vscode#65920, but only when remote debugging an ARM64 target

Environment

  • Ubuntu 20.04 x64
  • vscode 1.58.2 c3f1263
  • go1.16.5 linux/amd64
  • delve 1.7.0 and 1.6.0
  • gopls v0.7.0
  • vscode-go v0.26.0

Steps to reproduce

  • Create the same main.go used in the referenced issue
package main

import (
    "fmt"
    "time"
)

func main() {
    for {
        fmt.Println("Hello, World!")
        time.Sleep(2 * time.Second)
    }
}
  • Build and copy the program on the remote target, then start delve server
HOST="[email protected]"

GO111MODULE=off GOOS=linux GOARCH=arm64 go build -o repr .

scp ./repr $HOST:/usr/bin

ssh $HOST "dlv --headless --listen=:2345 --log --api-version=2 --accept-multiclient exec /usr/bin/repr"
  • Start debugging using the following launch configuration:
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "remote debug",
            "type": "go",
            "request": "attach",
            "mode": "remote",
            "remotePath": "",
            "port": 2345,
            "host": "192.168.1.26",
            "cwd": "${workspaceFolder}",
        }
    ]
}

I attached all the files needed to reproduce the problem (you'll need an ARM64 target, though)

@gopherbot gopherbot added this to the Untriaged milestone Jul 25, 2021
@hyangah
Copy link
Contributor

hyangah commented Jul 26, 2021

I guess this is a duplicate of #1617
This is a bug in the legacy debug adapter, and the newest dlv dap (built from the master) should mitigate the issue.

We are still working on improving remote debugging experience with dlv dap - can you please take a look if the current temporary workaround (and its limitation) described here https://github.com/golang/vscode-go/blob/master/docs/dlv-dap.md#remote-debugging works for your use case?

If not, can you try to downgrade vscode to 1.57 and confirm this is the duplicate of #1617 started with 1.58?

cc @polinasok @suzmue

ps. And, when you compile the target binary, please make sure to pass -gcflags='all=-N -l' flag.

@hyangah hyangah added the Debug Issues related to the debugging functionality of the extension. label Jul 26, 2021
@hyangah hyangah changed the title Debugging shifts focus to proc.go when stepping to next line during remote debugging debug: shifts focus to proc.go when stepping to next line during remote debugging Jul 26, 2021
@hyangah hyangah modified the milestones: Untriaged, v0.27.0 Jul 26, 2021
@gopherbot
Copy link
Collaborator

Change https://golang.org/cl/338194 mentions this issue: src/debugAdapter: send continued event on step requests

@polinasok polinasok added debug/legacy legacy debug adapter related issues - new issues won't be fixed Duplicate Make it obvious when issues are closed as duplicate labels Jul 28, 2021
@polinasok
Copy link
Contributor

polinasok commented Jul 28, 2021

ps. And, when you compile the target binary, please make sure to pass -gcflags='all=-N -l' flag.

After launching dlv dap externally, you can also use "mode": "debug" in launch.json to have dlv-dap do the compiling for you.

@debevv
Copy link
Author

debevv commented Jul 29, 2021

@hyangah yes, I tried dlv with DAP and it works much better. No weird jumps now
This is the configuration I used:

{
    "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",
}

And this is how i launch dlv on the target:

dlv dap --listen=:12345

I built delve from source, and for some reason I didn't get a dlv-dap binary, so I used plain dlv

After some trial and error, i discovered that I have to add "debugAdapter": "dlv-dap" to the launch config, otherwise vscode tries to run /usr/bin/repr on the local machine.

ps. And, when you compile the target binary, please make sure to pass -gcflags='all=-N -l' flag.

After launching dlv dap externally, you can use "mode": debug" in launch.json to have dlv-dap do the compiling for you.

Hi @polinasok , thanks for the tip. Just to clarify what I'm trying to do, in my case I don't build the executable on the target because it is an embedded device. So the target side I have only dlv and the (debug) binary

@polinasok
Copy link
Contributor

I built delve from source, and for some reason I didn't get a dlv-dap binary, so I used plain dlv

You can get dlv-dap binary from Control Panel with Go: Install/Update Tools.
The dlv binary that is downloaded by default with VS Code is the stable release that is usually refreshed around the time new go version is released, so it can be behind dlv-dap, which is a version on dlv built from master since it is still under active development. If you build your own version, that works too.

After some trial and error, i discovered that I have to add "debugAdapter": "dlv-dap" to the launch config, otherwise vscode tries to run /usr/bin/repr on the local machine.

This is very helpful feedback. Thank you. I am updating the documentation to include this missing attribute in the example.

After launching dlv dap externally, you can use "mode": debug" in launch.json to have dlv-dap do the compiling for you.

Hi @polinasok , thanks for the tip. Just to clarify what I'm trying to do, in my case I don't build the executable on the target because it is an embedded device. So the target side I have only dlv and the (debug) binary

Sure thing. Whichever way works. Just wanted to point out that you have more than one option (attach also), depending on your set up.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
debug/legacy legacy debug adapter related issues - new issues won't be fixed Debug Issues related to the debugging functionality of the extension. Duplicate Make it obvious when issues are closed as duplicate FrozenDueToAge
Projects
None yet
Development

No branches or pull requests

5 participants