-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
VS Code DAP does not map trimmed paths #2754
Comments
Could you include your launch / attach request from the logs as well? If you are using attach or launch exec, could you also include the build command that was used to build the executable you are debugging? |
Sure! Below
It was built with bazel (and I'll admit to be very unfamiliar with the ecosystem). I re-ran bazel with
|
I would suggest adding |
That unfortunately did not fix my issue. I'm working on creating a simpler reproducer with an open-source project. Will report back if I am successful. Thanks for the help so far! |
Ping |
Sorry for the delay on more info. Still working on a simpler reproducer. I’ll close this issue for now and re-open (or open a new one) once I have a reproducer. Thanks for the help so far. |
@SteVwonder Could you please get the logs one more time and show the rest of the DAP traffic starting from I think the issue is a relative path that triggers an on-the-fly request for a source file. If this were an absolute path that was not properly matched and didn't exist, we would have gotten
|
Bazel passes trimpath by default and no substitutePath mapping was specified. |
Looking at #2754 (comment) more closely, I see
and then @suzmue suggested @aarzilli, thanks for the |
Breakpoints are also a problem for me. I should have some time today to grab a new trace and try different substitution paths. Thanks for the help all! |
I believe the substitution path is now correct. Here is my vs code launch config:
and a little sanity scheck of the substitutionpath:
It is not the only stack frame causing issues. I have this problem for any attempt to access any of the source files in the as well as getting any of the breakpoints to work.
|
You put |
source
request not supported
Can you help me for windows, I'm unable to figure this part. As when I attach local debugger to process using dlv and add a breakpoint, it says could not find file |
@susarlanikhilesh here is a tip: VSCode Go also offers to do (1) and (2) from DEBUG CONSOLE ( -- |
You can also set
|
@polinasok only if the user managed to stop the debug session without breaking other parts of UI. ( |
I'm going to close this since it seems that we're not going to do any sort of automatic mapping for now and the original report was likely a configuration error. |
Is there a way to set a substitutePath that applies to all relative paths? "substitutePath": [
// I can't figure out how to set a single substitution for all paths,
// so I have to do it for each subdirectory of the workspace.
{
"from": "${workspaceFolder}/external/",
"to": "external/",
},
{
"from": "${workspaceFolder}/infra/",
"to": "infra/",
},
{
"from": "${workspaceFolder}/models/",
"to": "models/",
}
] |
@garymm It may not be an option for you, but if you switch to modules (instead of GOPATH) all of your source files are prefixed with the module name so "to" would be "example.com/your/module/". |
dlv version
)?go version
)?Windows 10 on x86_64 but running inside of WSL2 via VS Code's remote extension
Ran a go binary under
delve
via VS Code's debugging pane/tooling with theGo
extension installed. I stopped the execution of the program, and then clicked on a thread within the call stack frame. That opened up the call stack, and then I clicked on a particular stack frame.I expected to see the source code of the file containing the function for the stack frame that I clicked on.
A new source window in VS Code with the correct filename, but the contents were an error message from VS Code/delve:
Here is a sanitized version of the trace from VS Code of the DAP communication:
I'm not familiar with the delve codebase, but I believe the issue is here in the dap server code. It is responding with an unsupported error to all
source
requests. Curiously, the comment mentions that this command doesn't make sense for Go since strings cannot be eval'd at runtime, but the DAPSource Request
is not asking for code/commands to be source'd but instead for the debugger to return a particular piece of source code.The text was updated successfully, but these errors were encountered: