I run a process inside a docker container that needs to be debugged. The process is started in the docker's entry point via
dlv debug /go/src/path/to/package --headless --listen=:2345 --log
for the purpose of enabling debugging later in VSCode.
The docker container is started via
docker run --rm -it -p 2345:2345 my_image:tag
. Note delve's port is exposed.
In VSCode I define launch.json
as follows:
{
"version": "0.2.0",
"configurations": [
{
"name": "Attach remote",
"type": "go",
"request": "attach",
"mode": "remote",
"port": 2345,
"host": "127.0.0.1",
"apiVersion": 1
}
]
}
Upon starting the "attach remote" VSCode debugging configuration I get
It isn't crystal clear, but that UI leads me to believe I'm now connected to the remote headless debugger and ready to debug. I have one breakpoint defined which I know would be hit by a request I can send the remote process. I send that request, I get a result, and that breakpoint never hit, indicating that I haven't yet achieved remote debugging.
Is something wrong with my VSCode "attach remote" configuration? I can do command-line debugging with dlv connect :2345
and actually debug the remote process just fine, which indicates the headless server is functional. I would rather debug with source code, in VSCode though.
Try again with the latest beta of vscode-go (April 2020) (for any time after April 2020, the latest official vscode-go release will be enough)
Microsoft/vscode-go
issue 2010 includes this confirmation from Ramya Rao:
The fix from #3108 is available in the latest beta version of this extension. Please do try and share feedback
The latest version of the extension now has the fix to this issue
And:
I can confirm that I am able to hit breakpoints now using AWS SAM to launch a linux container with delve and go binaries compiled from Windows.
For anyone still having this problem (like I was before I edited this comment), take care that the "remotePath" element of your launch.json is the absolute path to the source files as compiled on your local system (not the container).
As implied above - it's the absolute local path that is added to the DWARF compilation unit file table when you compile the binary.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With