-
Notifications
You must be signed in to change notification settings - Fork 740
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
debug: delete legacy debug adapter #3096
Comments
Change https://go.dev/cl/550917 mentions this issue: |
And warn users who are affected by this change. For #2205 For #3096 Change-Id: Ie74b0f2d02b1f64d984d1120463f0b01328e2bb0 Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/550917 TryBot-Result: kokoro <noreply+kokoro@google.com> Reviewed-by: Suzy Mueller <suzmue@golang.org> Commit-Queue: Hyang-Ah Hana Kim <hyangah@gmail.com>
I Cannot make the breakpoint. |
Same VS CODE:
VS CODE launch config:
App runs in docker via: |
i am trying to attach to a vscode version/env:
vscode launch config: "launch": {
"configurations": [
{
"name": "my-remote-service",
"type": "go",
"request": "attach",
"mode": "remote",
"remotePath": "/app",
"port": 5555,
"host": "127.0.0.1",
"showLog": true,
"logOutput": "rpc"
}
],
}, the dlv --listen=:5555 --headless=true --api-version=2 --accept-multiclient exec /server any help is highly appreciated! br |
workaround for the meantime: "go.delveConfig": {
"debugAdapter": "legacy"
} ! be sure to track this issue and remove this config again! |
I added a new file settings.json under project/.vscode/settings.json with the above suggested content, restarted VSC, but still, I could not set break point (showing a circle but not in red). The BPs will display in red only when the debugger is not active. Edit: gm0stache was right. Adding changes to settings.json works for all VSC instances, while adding to launch.json only works for that instance. The location of the VSC settings.json is at: C:\Users\myuserid\AppData\Roaming\Code\User\settings.json ........
} |
same - can't make a breakpoint. |
This worked for me as well. Thanks |
This worked for me as well. Need to add this field inside the object under the |
I discovered that I couldn't make a breakpoint today either. I was under time pressure to resolve an issue and this caused a very frustrating delay. |
same problem for me. I couldn't add a breakpoint and it was fixed when adding "debugAdapter": "legacy". |
Same problem. Could not set breakpoints with dlv running in a remote Linux virtual machine and VS code running on windows. |
Same. Using legacy debug adapter works for remote debugging. Whatever the new thing is, it doesn't work. |
Without "debugAdapter": "legacy" config,I cannot set any breakpoint . |
Same problem, and when I try to add "debugAdapter": "legacy" config, I get the following error:
|
related issue: #3096 (comment) |
I'm getting a "Legacy debug adapter is deprecated. Please comment on issue 3096 if this impacts your workflows." message when I debug locally. The configuration I'm running has: |
Same here. |
same here |
Also this partially helps, but I still can't add breakpoints in dependency libraries #3175 |
I can't debug with new dvl-dlp adapter. |
And I've just fucked up a tech assessment because of this shit. |
Like others here, I couldn't add a breakpoint without using the legacy adapter. The issue is that the file in which the breakpoint is being added can't be found. Interestingly, this is the same problem I'm experiencing with Neovim's dap. I'd love to know what the legacy adapter does that the new adapter doesn't do. It might help me to fix my neovim dap configuration. Then I can have the option of using VSCode or Neovim. |
The same problem. Can't add breakpoint without {
"name": "service_name",
"type": "go",
"request": "attach",
"mode": "remote",
"remotePath": "",
"port": 40000,
"host": "127.0.0.1",
"showLog": true,
"trace": "log",
"logOutput": "rpc"
} |
Thanks for all of the feedback! The legacy debug adapter attempts to match the files from the VS Code client to a list of files that are in the compiled binary (#45), whereas the dlv dap relies on manual configuration. It is clear from the comments on this issue and #3175 that dlv dap does need to have a solution for this problem beyond manual configuration. We have decided to revert the change of the default back to legacy for remote attach in v0.41.3 and will address this breakpoint issue by adding automated path mapping to dlv dap, which will require changes in both delve and vscode-go. The work on automated path mapping will be tracked in #3193. |
thanks for addressing the issue! |
We're using the legacy adapter so that we can debug bazel (rules_go) managed binaries from within VS code (parts of the small wrapper to make it work: https://gist.github.com/bluec0re/af19ded857749fd2ec145f4e06f0e9b3). |
Got this error
|
@91diego Can you check the versions of |
It's been more than two years since we switched to dlv dap, and we halted any more dev/maintenance work for legacy debug adapter.
The legacy debug adapter is still being used as the default for "remote" debugging, but we also see an increased number of users switched to dlv-dap for remote debugging. (e.g. forked vscode-go for bazel, etc)
Before the deletion, we are going to switch the default (#2205) by warning potentially affected users and directing them to this issue.
(Update: 2024-04-04) Please see #3096 (comment)
Known issues:
substitutePath
setting, as described in this comment. We are currently working on automated path mapping. Improve automated path mapping in dlv debug adapter #3193The text was updated successfully, but these errors were encountered: