debuger didn't hit any breakpoints when open a soft link code folder

[youngqqcn]

• delve is latest
• go version: 1.16.5
• os: ubuntu20.04

It's a very strange issue. I'm not sure the this issue belong to visual code or delve.

My code folder absolute path is /data2/work/mycode. I made a soft link to ~/mycode. I opened the code folder by code ~/mycode , then the golang debuger didn't stop at any breakpoint.

If I open folder by absolute path , such as code /data2/work/mycode , the golang debuger will hit the breakpoints.

[aarzilli]

cc @polinasok

[suzmue]

Could you try setting substitutePath in your launch configuration?:

"substitutePath": [{"from": "/homedir/mycode", "to": "/data2/work/mycode"}]

https://github.com/golang/vscode-go/blob/master/docs/debugging.md#debugging-symlink-directories

If that doesn't work, could you capture the logs and include them? (instructions here: https://github.com/golang/vscode-go/blob/master/docs/dlv-dap.md#code-location)

[polinasok]

It's likely the issue with the vscode setup. Symlinks are known not to always work right with it out of the box.
For example: golang/vscode-go#1458, golang/vscode-go#622

In general, you can confirm that dlv is not at fault by using its cli. For example:

$ ln -s helloworld/ helloworld_ln
$ dlv debug helloworld_ln
Type 'help' for list of commands.
(dlv) b helloworld.go:26
Breakpoint 1 (enabled) set at 0x10c4b38 for main.main() ./helloworld_ln/helloworld.go:26
(dlv) c
> main.main() ./helloworld_ln/helloworld.go:26 (hits goroutine(1):1 total:1) (PC: 0x10c4b38)
 ...
(dlv) b ./helloworld_ln/helloworld.go:28
Breakpoint 2 (enabled) set at 0x10c4b54 for main.main() ./helloworld_ln/helloworld.go:28
(dlv) c
> main.main() ./helloworld_ln/helloworld.go:28 (hits goroutine(1):1 total:1) (PC: 0x10c4b54)
...
(dlv) b ./helloworld/helloworld.go:28
Command failed: location "./helloworld/helloworld.go:28" not found
(dlv)

Using code helloworld_ln, you might be able to see the symlink path when setting and hitting a breakpoint:

But depending on the specifics of your system, you likely do need to use substitutePath in your launch configuration to map symlink path to actual path.

Also, when filing vscode-go issues, it always helps if you include your launch.json configuration and provide detailed logs (enabled with "trace": "verbose", "showLog": true, "logOutput":"debugger,dap,rpc" in your launch.json configuration), so we know exactly what requests were made to dlv.

@suzmue

[aarzilli]

Presumably solved by substitutePath configuration option.