Error on CreateBreakpoint: could not find file (macOS) when using trimpath in GOFLAGS

[jorng]

Unable to set any breakpoints in any files.

Using go1.13.1, modules on. Even with basic “Hello world”. No matter what, I see the error in the title, followed by a full path to my main.go.

[jorng]

For example, given the project:

/Users/jorng/dev/hello
├── go.mod
└── main.go

0 directories, 2 files

go.mod

module hello

go 1.13

main.go

package main

import "fmt"

func main() {
	fmt.Println("Hello, world!")
}

launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch",
            "type": "go",
            "request": "launch",
            "mode": "auto",
            "program": "${fileDirname}",
            "env": {},
            "args": [],
            "trace": "log",
        }
    ]
}

---

I set a breakpoint on main.go:6, and when attempting to debug, it does not break, and I receive the following output on the debug console:

Verbose logs are written to:
/var/folders/1q/384f3pd90792pks1my1yq2040000gn/T/vscode-go-debug.txt
InitializeRequest
InitializeResponse
Using GOPATH: /Users/jorng/dev/go
Current working directory: /Users/jorng/dev/hello
Running: /Users/jorng/dev/go/bin/dlv debug --headless=true --listen=127.0.0.1:29879 --api-version=2
API server listening at: 127.0.0.1:29879
InitializeEvent
SetBreakPointsRequest
All cleared
Creating on: /Users/jorng/dev/hello/main.go:6
Error on CreateBreakpoint: could not find file /Users/jorng/dev/hello/main.go
All set:[null]
SetBreakPointsResponse
ConfigurationDoneRequest
ContinueRequest
ContinueResponse
Hello, world!
continue state {"Running":false,"Threads":null,"NextInProgress":false,"exited":true,"exitStatus":0,"When":""}
TerminatedEvent
DisconnectRequest
HaltRequest
HaltResponse
Failed to halt - Process 43328 has exited with status 0
DetachRequest
DisconnectRequest to parent
DisconnectResponse

[ramya-rao-a]

Are you using symlinks?

[jorng]

No. It happens even with brand new projects.

[jorng]

If I try to run the command via dlv directly it's the same issue:

(dlv) break /Users/jorng/dev/hello/main.go:6
Command failed: Location "/Users/jorng/dev/hello/main.go:6" not found

But if I use a relative file path from the root of the project, it works perfectly:

(dlv) break main.go:6
Breakpoint 1 set at 0x109925d for main.main() hello@/main.go:6

Should it really be using full paths?

[jorng]

OK, so I figured out what is going wrong here: I have GOFLAGS="-trimpath" set in my go env.

I wouldn't have thought that would make a difference, but since VSCode is using the full (absolute) path to files, that is where the issue lies. The binary does not have a full filepath, only relative paths from the root of the project. (That might also explain why it won't work with symlinks)

So is there a specific reason for using full absolute paths? Couldn't we use relative paths?

[ups91]

Here https://github.com/bazelbuild/rules_go/issues/1844 men bump into similar conclusion

[vshkola]

Hi,

Here are open issues : #2010 and bazelbuild/rules_go#1844

I also getting the same problem on MacOS 10.14.6, dlv b handlers/handler.go works, dlv b /Users/macUser/go/src/projectName/handlers/handlers.go couldn't find a file.

In my case I don't use GOFLAGS="-trimpath".

VSCode with launch.json

{
            "name": "Remote debug",
            "type": "go",
            "request": "attach",
            "mode": "remote",
            "remotePath": "${workspaceFolder}",
            "port": 2345, 
            "host": "127.0.0.1", 
            "showLog": true,
            "trace": "log",
            "logOutput": "rpc"
}

also gives
Error on CreateBreakpoint: could not find file /Users/macUser/go/src/projectName/handlers/handlers.go

Docker container with headless delve-server running on 127.0.0.1:2345
I also was able to get dlv source visualisation with

substitute-path:
  - {from: /go, to: /Users/macUser/go}

Any updates on this topic @ramya-rao-a ?

[quoctruong]

@jorng What if instead of "program": "${fileDirname}", you use something like "program": "<relativePath>"?

[quoctruong]

@vshkola, I think you are not specifying the path mapping correctly. remotePath should be the path to the program on the server and cwd should be the path to the program on the host machine (so should be something like "cwd": "${workspaceFolder}" and remotePath: "<remote path>".

[ramya-rao-a]

There are two different issues being discussed here.

• Case when -trimpath is set in the GOFLAGS which is what the original issue logged by @jorng is related to
• Case when remotePath is not configured properly which is what is the case is for @vshkola

I'll update the issue title to reflect the trimpath situation and to cater to the first issue listed above.

@jorng, @quoctruong, Passing relative path to program attribute does not help at the moment as we expect this to be an absolute path to determine the current working directory and the package to be debugged.

See https://github.com/microsoft/vscode-go/blob/0.11.9/src/debugAdapter/goDebug.ts#L347-L368 and https://github.com/microsoft/vscode-go/blob/0.11.9/src/debugAdapter/goDebug.ts#L381-L385 and https://github.com/microsoft/vscode-go/blob/0.11.9/src/debugAdapter/goDebug.ts#L440

Folks are welcome to investigate what work is needed to support relative paths to the program attribute

[ngkamperlo]

Case when remotePath is not configured properly which is what is the case is for @vshkola

Hello, I had the exact same problem with @vshkola and what helped me was to set the remote path as follows:
say your Dockerfile has the declaration
COPY . /myapp
The solution would be to add to your launch.json
remotePath": "/myapp/"

[quoctruong]

@jorng This is now fixed in the nightly Go build (https://github.com/golang/vscode-go). Please give it a try: https://github.com/golang/vscode-go/blob/master/docs/nightly.md

[stamblerre]

Please follow the discussion on golang#45 or file a new issue if this still isn't working for you.