Failed to call CreateBreakpoint when path contains a symlink

[richardbowden]

go-debug fails to set breakpoints when run if the path for GOPATH contains a symlink, for example:

/Users/richard/dev -> /Users/richard/Documents/development

project loaded in atom from this path /Users/richard/dev but as you can see, the paths shown below are for the full path.

In this situation the following errors show up in go-debug consul:

Starting delve with "/Users/richard/Documents/development/go/src/github.com/richardbowden/passwordHash/example/main.go" with "debug" Delve output: 2016/07/26 14:04:28 server.go:71: Using API v1 2016/07/26 14:04:28 debugger.go:61: launching process with args: [./debug] Started delve with "/Users/richard/Documents/development/go/src/github.com/richardbowden/passwordHash/example/main.go" with "debug" Adding breakpoint: /Users/richard/Documents/development/go/src/github.com/richardbowden/passwordHash/example/main.go:24 API server listening at: 127.0.0.1:2345 Failed to call CreateBreakpoint error: unknown file: /Users/richard/Documents/development/go/src/github.com/richardbowden/passwordHash/example/main.go Adding breakpoint failed: /Users/richard/Documents/development/go/src/github.com/richardbowden/passwordHash/example/main.go:24 error: unknown file: /Users/richard/Documents/development/go/src/github.com/richardbowden/passwordHash/example/main.go

When using the absolute (no symlinks) path for GOPATH go-debug works perfectly.

for clarity, this path does work. ~/Documents/development/go

[targodan]

I have the same issue. My setup looks like this:

$GOPATH
├── ...
├── src
│   ├── myproject -> ~/Development/myproject
│   │    └── ...

I do this because I prefer to work in the ~/Development/myproject folder and get the same error as @richardbowden.

I guess it would work for me to create the link in the opposite direction but this is mildly anoying and I would classify this as a bug.

[targodan]

Did a little further investigation and here is what I found

• Settings breakpoints only fails if they are in a different file from the one being executed. So if you execute test.go and want a breakpoint in test.go:12 it works, but if you want one in dependancy.go:12 it fails.
• I tried executing atom in $GOPATH/src/myproject and in ~/Development/myproject - Same result, same error
• I tried executing delve in a terminal, setting breakpoint using relative paths - Works just fine
• I tried executing delve in a terminal, setting breakpoint using an absolute path to the original (as go-plus seems to do) - Results in Command failed: Location "/home/USER/Development/myproject/myfile.go:12" not found the path is valid though.
• I tried executing delve in a terminal, setting breakpoint using an absolute path to the symlink (i. e. $GOPATH/myproject/myfile.go:12) - Works just fine

Just to validate, I also tried to execute delve with a no-symlink setup and here both relative and absolute paths work.

Context

If not stated otherwise all tests are run in the symlink-setup, having atom/delve run in the original (not the symlink) folder.

My Conclusion

This sounds like using delve with relative paths would solve the problem.

However contradicting my classification in my last post: I am not sure if this is the desired behaiviour. As go is (from what I have learned so far) very dependant on the GOPATH this might be ok in order to force/teach people to work in the GOPATH. If so the error message should be changed to something more verbose. Maybe something like "The given location is not part of the GOPATH folder. Please move the folder.". Of course this would have to be done upstream. I guess I'll open an issue there to discuss this.

[lloiser]

Awesome! Thanks for having a look at it and adding an issue/discussion to delve! I guess I'll wait with this issue until there is a conclusion over there.

[targodan]

Ok, so I closed the upstream issue because they convinced me that it's not a bug (at least not in delve) because it only uses files it can find in the debug information of the executable. And it doesn't have anything to do with the gopath either.

So let's say you two folders a and b with a pointing to b. If go decides to compile in folder a and you try to set a breakpoint in folder b it will fail, and vise versa.

Since it seems like go does something weird with symlinks (maybe it resolves them before compilation) I would suggest to use relative paths in go-debug in order to have it work under (hopefully) any circumstances. Even if us strange users decide to do weird stuff with symlinks. :wink:

[targodan]

I just forked and experimented a bit. And it seems like just making the paths relative is not enough to make it work. See here for how I've done it.

Yes this duplicates the breakpoints on every go but I got the delve output panel to show Adding breakpoint: test.go:6 instead of the full path. However I still get an error: error: unknown file: test.go

Maybe this is due to a different working directory of the delve instance (haven't found that part in your code yet) or we need to do some clever checking of which paths the go compilier used somehow.

This was just a quick and rather dirty test, when I get the time I'll investigate this further.