Debugging won't start if there is an unrecognised breakpoint in remote debugging #1762
Labels
debug/legacy
legacy debug adapter related issues - new issues won't be fixed
Debug
Issues related to the debugging functionality of the extension.
FrozenDueToAge
Projects
Milestone
Comments
|
Is it necessary to have two conflicting main packages in the same directory?
EDIT: It looks like the failure was not due to the failed go commands, but bugs in path mapping that happen when the file is not included in the file list of the target binary. |
hyangah
added
the
Debug
This comment has been minimized.
This comment has been minimized.
I don't think this is related. The user session shows no error messages. Your log points to a new issue in Nightly, not released version. I just ran into it myself. It is not limited to any one mode. Filed #1764. |
|
Thanks for pointing out. @polinasok Can you capture the log for this original issue? |
polinasok
added
the
debug/legacy
|
So in theory this should try to set a breakpoint in The breakpoint in However, without any And the adapter itself doesn't respond to the client either. For the two breakpoint requests it receives, only one response is sent back. This looks like a bug in the path mapping inference code. I haven't dug deep to fully understand where it gets stuck though. As we are working towards supporting remote mode with the new dlv-dap adapter, we are planning to deprecate this automated inference logic in favor of |
|
Unrelated to the issue, you should build the binary with |
|
Change https://golang.org/cl/348972 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Sep 10, 2021
When there is no matching candidate inside the target binary, remoteSourcesAndPackages.remoteSourceFilesNameGrouping won't have corresponding files and potentialPaths can be undefined. At least, made me continue debugging the example described in issue #1762. Not sure if that's the end of the bugs yet. Updates #1762 Change-Id: I2b69beb45397b0ea102a343ad6aad884c304f6b4 Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/348972 Trust: Hyang-Ah Hana Kim <hyangah@gmail.com> Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: kokoro <noreply+kokoro@google.com> Reviewed-by: Polina Sokolova <polina@google.com>
|
I verified v0.28.0-rc.2 fixed the repro example included in the original report. Closing. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Go, VS Code & VS Code Go extension are you using?
Version Information
go versionto get version of Go from the VS Code integrated terminal.gopls -v versionto get version of Gopls from the VS Code integrated terminal.code -vorcode-insiders -vto get version of VS Code or VS Code Insiders.0.27.2
Go: Locate Configured Go Toolscommand.Share the Go related settings you have added/edited
"go.toolsManagement.autoUpdate": true,
Describe the bug
When I have breakpoints from a different binary in vscode, and I attempt to attach vscode to a listening instance of delve, it connects, but you cannot start running the binary.
I expect to be able to run a binary, even if I have invalid breakpoints.
Steps to reproduce the behavior:
go build hello.godlv exec $(pwd)/hello --api-version=2 --headless --listen=:2345)Screenshots or recordings
https://streamable.com/fzcxdi
The text was updated successfully, but these errors were encountered: