Go Remote debugging: the editor does not open the source file

Problem

A Go Remote run/debug configuration connects to Delve on a remote machine or in a container. The debugger stops on a panic or on a breakpoint and the stack frames appear, but the editor does not open the matching source file. Breakpoints render as a circle with a slash instead of a red dot.

Cause

GoLand maps remote source paths to local files automatically, which is why the configuration has no mapping table. The build directory does not have to exist locally: a binary built in a directory that was deleted afterwards still resolves its frames to the project.

The mapping is built one file at a time. A frame resolves to a local file only when a breakpoint was set in that file before the stop, so a panic can produce a complete stack and no editor.

GoLand sends no substitution rules to Delve, so Delve's own substitute-path option has no effect on a GoLand session.

Resolution

1. Set a line breakpoint in each file the editor needs to open, before reproducing the problem. Any line in the file works.
2. Open the sources that produced the binary in the local project.

The full remote setup, including the build flags Delve needs, is documented in Attach to running Go processes with the debugger.

Bazel projects

Bazel records source paths relative to the execution root, for example greet/greet.go, so a binary built in a container carries the same strings as one built locally. These relative paths resolve without the Bazel plugin installed.

The Bazel plugin registers its own path converter ahead of the built-in one. When it cannot match a path, it writes a warning to idea.log:

Server could not resolve remote path '<path>' to local path.

The line names the path recorded in the binary. Comparing it against the project layout shows which prefix does not match.

The Bazel plugin in a project that does not use Bazel

With the Bazel plugin enabled, Go Remote debugging fails in a project that has no MODULE.bazel. The plugin's converter runs for every Go debug session, and in such a project it throws, which leaves the session with no converter at all. Breakpoints never bind, no frames appear, and a .bazelbsp directory is created in the project root. idea.log records:

java.lang.IllegalStateException: Querying bazel info failed.

Disable the Bazel plugin in projects that do not use Bazel. This is tracked in Go Remote debugging broken in non-Bazel projects when the Bazel plugin is enabled.

If the file still does not open

GoLand can match a file to a different file with the same name, for example one in the Go SDK, which leaves the breakpoint disabled. That defect is open and tracked in Remote Process Debugger unable to infer source code files correctly.

1. Reproduce the session once with the Go Remote configuration.
2. Select Help | Collect Logs and Diagnostic Data from the main menu.
3. Upload the resulting ZIP file to uploads.jetbrains.com and send the Upload ID to support.