Golang

2230 readers

1 users here now

This is a community dedicated to the go programming language.

Useful Links:

Rules:

Posts must be relevant to Go
No NSFW content
No hate speech, bigotry, etc
Try to keep discussions on topic
No spam of tools/companies/advertisements
It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

founded 2 years ago

MODERATORS

Ategon

RandomDevOpsDude

austin

VSCode: Debugging Attached Process does not work (lemmy.world)

submitted 5 months ago by [email protected] to c/golang

6 comments fedilink hide all child comments

I made some Go scripts that require user input fmt.Scanln(&fileName) during the execution. When I use the Go debugger built into VSCode which is the launch type, it works but there is no way to enter any prompts when your exeuctable asks for a input. With other programming languages like NodeJS and PHP, there is way to run the scripts in "debugging mode" where it will run the code but before it executes the code, it will wait to attach to a debugger on your system and then execute the code. This has always allowed me to use the terminal for inputs in the executable.

For example to do this in NodeJS, you will use node --inspect-brk=0.0.0.0 main.js instead of node main.js and then run the debugger in VSCode to attach it to the executing script. Is there a way to do this with Go? Do I need to set something up to achieve this?

I am on Linux Mint and cannot find any commands to run go run . but to wait for a debugger to attach to the executable before executing.

top 6 comments

sorted by: hot top controversial new old

[–] [email protected] 2 points 5 months ago

I think this should fix it https://stackoverflow.com/a/78162844

[–] firelizzard 2 points 5 months ago (1 children)

Attaching to and debugging a process most certainly does work. I did it yesterday. Your issue is that Go doesn’t have any way of telling the process to pause until a debugger attaches. Which is frustrating but not the same issue.

Specifically for debugging stdin, by far the easiest way to do that (in VSCode) is "console": "integratedTerminal". Another comment links a stack overflow answer that includes other options.

[–] [email protected] 1 points 5 months ago (1 children)

This solution does with when using a launch request in the config. Thank you

Do you have a simple guide by chance on how to get debugging to work inside a docker container using VSCode?

[–] firelizzard 2 points 5 months ago (1 children)

The TL;DR is that you have to exec —privileged and execute dlv attach within the container then tell VSCode to connect. I’ll look up my notes tomorrow and post more details.

[–] [email protected] 1 points 5 months ago (1 children)

I’ll look up my notes tomorrow and post more details.

Thank you. Been struggling to get my IDE setup for go development.

[–] firelizzard 2 points 5 months ago

Sorry, I forgot about this. I've attached my full configuration at the end. The steps are:

If the container is on a server, SSH to it or whatever.
Execute docker exec --privileged -it container_name bash.
- --privileged is required to make delve work. I don't entirely remember why.
- -it is something like --interactive and --terminal, it's what you need to get a proper interactive shell.
- container_name is the name of your container.
- bash can also be sh or pwsh or whatever shell your container has (hopefully it has one).
Launch delve dlv attach PID --headless --listen=:2345 --accept-multiclient --api-version=2.
- PID is the ID of the process you want to debug. This should be 1 if you're debugging the main process of the container.
- --listen=:2345 says to listen on (TCP) port 2345 on all interfaces (0.0.0.0)
- The other flags are the one that vscode-go expects.
If the container is on a server, forward ports ssh ${USER}@${SERVER} -NL LOCAL:2345:REMOTE:2345.
- LOCAL is the local IP to listen on, usually localhost. When a process connects to your local IP, it will be forwarded to the remote.
- REMOTE is the remote IP to connect to, this should be the IP of your container. When a connection is forwarded from your local machine, this is where it is forwarded to. My containers are set up with --net host so I can use localhost as REMOTE but that's not the default so you may have to use docker inspect to figure out your container's IP.

I also included the path substitution configs I use. I generally debug these by pausing the target, clicking on something in the stack trace, seeing what path it tries to load, then adjusting the substitute path so that it loads the correct file.

{
  "name": "Attach to a docker container",
  // Get a shell in the container: `docker exec --privileged -it ${NAME} bash`
  // Launch delve:                 `dlv attach 1 --headless --listen=:2345 --accept-multiclient --api-version=2`
  // Forward the port (if remote): `ssh ${USER}@${SERVER} -NL localhost:2345:localhost:2345`
  // Then run this debug config
  "presentation": {
    "group": "99-Miscellaneous",
  },
  "type": "go",
  "request": "attach",
  "mode": "remote",
  "remotePath": "${workspaceFolder}",
  "port": 2345,
  "host": "127.0.0.1",
  "substitutePath": [
    // // Full paths (GitLab Docker build)
    // {
    //   "to": "/go/",
    //   "from": "${env:HOME}/go/", // <-- MODIFY THIS if you're not using the default GOPATH
    // },
    // {
    //   "to": "/root/",
    //   "from": "${workspaceFolder}",
    // },
    // Trimmed paths
    {
      "to": "gitlab.com/accumulatenetwork/accumulate/",
      "from": "${workspaceFolder}/",
    },
    {
      "to": "github.com/AccumulateNetwork/",
      "from": "${env:HOME}/go/pkg/mod/github.com/!accumulate!network/", // <-- MODIFY THIS if you're not using the default GOPATH
    },
    // {
    //   "to": "",
    //   "from": "${env:HOME}/go/pkg/mod/", // <-- MODIFY THIS if you're not using the default GOPATH
    // },
  ],
}