this post was submitted on 20 Jul 2024
6 points (100.0% liked)
Golang
2197 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 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.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?
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.
Thank you. Been struggling to get my IDE setup for go development.
Sorry, I forgot about this. I've attached my full configuration at the end. The steps are:
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 besh
orpwsh
or whatever shell your container has (hopefully it has one).dlv attach PID --headless --listen=:2345 --accept-multiclient --api-version=2
.PID
is the ID of the process you want to debug. This should be1
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)ssh ${USER}@${SERVER} -NL LOCAL:2345:REMOTE:2345
.LOCAL
is the local IP to listen on, usuallylocalhost
. 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 uselocalhost
asREMOTE
but that's not the default so you may have to usedocker 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.