Delve isn't able to find any of my source files, so it doesn't stop at any breakpoints

[davidmichaelkarr]

Please answer the following before submitting your issue:

Note: Please include any substantial examples (debug session output,
stacktraces, etc) as linked gists.

1. What version of Delve are you using (dlv version)?
   1.7.1
2. What version of Go are you using? (go version)?
   1.17.3
3. What operating system and processor architecture are you using?
   Linux Ubuntu/amd64
4. What did you do?
   Using vscode with the vscode-go extension, I created a multimodule/multipackage/multifolder project (although still pretty small), where one module uses cgo. The project has no compile errors, and it starts up successfully, although it has operational issues in testing, which is simply issues with my application code.

I set a breakpoint on the first line of the main function, which is a print statement. When I start the debugger, I see the print statement in the console log, but it doesn't stop at the breakpoint. When the application starts, the breakpoint red circle changes to a hollow circle, and when I hover on that, it prints "could not find file /home/dk068x/git/voltagego/main.go". That path is valid, and the file does exist.

The start of the log shows this:

Starting: /home/dk068x/go/bin/dlv-dap dap --check-go-version=false --listen=127.0.0.1:41147 --log-dest=3 from /home/dk068x/git/voltagego
DAP server listening at: 127.0.0.1:41147

Note that I had worked on another application in vscode-go, and when I switch to that, even without bringing vscode down, and then run that in the debugger, it stops at breakpoints. That application is much simpler, being a single module.

5. What did you expect to see?
   For the debugger to stop at the breakpoint.
6. What did you see instead?
   It didn't stop at the breakpoint.

[aarzilli]

Any symlinks in the path of main.go? cc @polinasok

[davidmichaelkarr]

Yes, one directory in the path is a symlink to another directory on the VM, and perhaps unrelated, that path is within a VirtualBox shared folder path, so the actual files reside on the Windows host (I run Ubuntu on a VirtualBox VM on a Windows 10 host).

[aarzilli]

It is likely that go is resolving those symlinks while compiling and the executable contains the real path of the files rather than what vscode thinks is the path. There is a substitute path option in launch.json for this.

[davidmichaelkarr]

I'd appreciate a little more information. How exactly do I resolve this?

Whether I can resolve it or not with this "substitute path" option you refer to, it does seem like this would be considered a bug. Are you saying that this is something that Go is doing, and not delve or vscode-go?

[davidmichaelkarr]

Ok. I found:
"An array of mappings from a local path (editor) to the remote path (debugee). This setting is useful when working in a file system with symbolic links, running remote debugging, or debugging an executable compiled externally. The debug adapter will replace the local path with the remote path in all of the calls."

Ok, so "/home/dk068x/git" is a symlink to a different path. Now I have to figure out the syntax of this property. I don't even see this property mentioned at https://code.visualstudio.com/docs/editor/debugging#_launch-configurations , nor do I see any mentions of it on a wider search.

I tried this, which at least doesn't complain in the editor:

        "substitutePath": [{"/home/dk068x/git": "/media/sf_winhome/git"}]

This fails at launch, saying "requires both 'from' and 'to' entries".

[suzmue]

The entry in your launch config should look like:

        "substitutePath": [{"from": "/home/dk068x/git", "to": "/media/sf_winhome/git"}]

substitutePath is a go specific launch configuration so it does not appear in the general vscode documentation.

[davidmichaelkarr]

Excellent. That worked. Note that I also don't see this mentioned at https://code.visualstudio.com/docs/languages/go .