GoLand's Integrated Delve Debugger: Configuration, Mechanism, and Limits

The short answer

GoLand includes JetBrains' Delve integration, so you can debug Go programs directly from the IDE using line breakpoints, step controls, variable watches, and the Debug tool window without manually installing Delve. When you start a Debug configuration, the IDE compiles your code with debug metadata, launches Delve as a backend, and suspends execution at your breakpoints so you can inspect locals, goroutines, and the call stack.

How GoLand runs your program under Delve

GoLand does not simply attach to an already-running process. It performs three coordinated steps. First, it builds the target with debug information and disables compiler optimizations that would obscure source mapping—typically by passing flags equivalent to -gcflags="all=-N -l" so the compiler does not inline functions or reorder code. Second, it starts Delve as a headless backend bound to a local port. Third, it translates IDE actions—toggling a breakpoint, stepping over a line, expanding a struct—into Delve protocol requests and renders the responses in the Debug tool window.

Because the IDE controls the build flags, a Debug run is intentionally different from a production build. The binary is larger and slower, but source lines map accurately to compiled addresses, which is what makes line breakpoints and variable inspection reliable.

A worked local debugging configuration

To debug a standard command-line binary, open Run > Edit Configurations, add a Go configuration, and set the Program file field to cmd/app/main.go. Place a line breakpoint on a fmt.Println call, then click the Debug icon. GoLand compiles the package with debug flags, starts Delve, and suspends the process at the breakpoint.

When suspended, the Debug tool window shows several panes. The Variables pane lists in-scope locals and their current values. The Frames pane shows the call stack for the selected goroutine, and the goroutine dropdown lists other active goroutines. You can step over, step into, or step out using the toolbar or keyboard shortcuts. If the Variables pane is empty or shows <optimized out>, the build likely did not include the debug flags described above.

Checking the toolchain

Before relying on the debugger, confirm the Go toolchain that GoLand is using. Run go version in the GoLand terminal (or any system shell with Go on the PATH). The output tells you the active toolchain. Compare this with the GoLand release notes, because the bundled Delve version and the set of supported Go toolchains change between IDE releases. If your Go version is newer than what the bundled debugger supports, you may need to update GoLand or configure a compatible toolchain.

Limits that change how you debug

The integrated debugger is powerful, but several limits affect day-to-day use.

• Inlined and optimized code: Conditional breakpoints and expression evaluation are unreliable when functions are inlined or when the binary is aggressively optimized. A breakpoint inside an inlined function may not trigger, or the process may suspend at an unexpected source line.
• Remote debugging: Remote debugging requires the remote Delve binary to speak the same protocol version as your GoLand installation. You must also manually forward the Delve port from the remote host to your workstation. For example, run ssh -L 4040:localhost:4040 <user>@<remote-host> in your local terminal; this requires valid SSH credentials for the remote host. The remote Delve process must listen on the forwarded port, and a version mismatch will typically surface as a protocol error when GoLand tries to attach.
• CGo boundaries: Symbol support across CGo is partial. Stack frames that cross into C code may be incomplete, and variables defined on the C side may not appear in the Variables pane.
• Version sensitivity: Bundled Delve versions differ between GoLand releases. A newer Go toolchain may require an IDE update or a compatible bundled debugger before breakpoints resolve correctly.

Common mistakes that break the session

Most debugging frustrations in GoLand come from a small set of mistakes.

• Running a non-debug build: If you build with go build and manually attach, or if you disable the IDE's debug flags, variables may be optimized away and the call stack may be inaccurate. Always start the session from the IDE's Debug action rather than attaching to an optimized binary.
• Breakpoints in generated or test-only files: Code produced by generators (for example, stringer or mock files) or files guarded by build tags that are not active in the current configuration may not map to the debug binary's address space. The breakpoint appears valid in the editor but never triggers.
• Expecting live updates while running: Delve suspends the process when a breakpoint hits. Variables and the call stack refresh only while the program is stopped. If you resume execution, the panes freeze at the last suspended state until the next breakpoint.
• Using Stop instead of Detach: The Stop action kills the debugged process. If you want the target to continue running after you finish inspecting it, use Detach instead. Stop is appropriate when you want to terminate the process and end the session.

Verifying the result

A practical way to confirm the debugger is working is to create a minimal main.go with a single fmt.Println line, add a line breakpoint, and start a Debug configuration. If the session is healthy, GoLand suspends at the breakpoint and the Variables pane populates with in-scope values. If it does not, check the toolchain version with go version, open Help > About to note the GoLand and bundled Delve build numbers, and compare them against the release notes for your Go version. For remote sessions, verify that the forwarded port is reachable and that the remote Delve version matches the protocol expected by your IDE.