What causes "selected goroutine not running" in go-delve/delve?

Select the goroutine that is currently stopped at the breakpoint (the one hit by the debugger) before issuing 'call'

selected goroutine not running

Error message

selected goroutine not running

What it means

errGoroutineNotRunning is returned by EvalExpressionWithCalls and evalCallInjectionStart when the selected goroutine exists but is not in the Running state; injected function calls can only be executed on a goroutine that is currently running on a thread and stopped at a safe point.

Source

Thrown at pkg/proc/fncall.go:63

//  - evalCallInjectionCopyArg
//  - evalCallInjectionComplete
//
// When the target has runtime.debugPinner then evalCallInjectionPinPointer
// must be also called in a loop until it returns false.

const (
	debugCallFunctionNamePrefix1 = "debugCall"
	debugCallFunctionNamePrefix2 = "runtime.debugCall"
	maxDebugCallVersion          = 2
	maxArgFrameSize              = 65535
)

var (
	errFuncCallUnsupported        = errors.New("function calls not supported by this version of Go")
	errFuncCallUnsupportedBackend = errors.New("backend does not support function calls")
	errFuncCallInProgress         = errors.New("cannot call function while another function call is already in progress")
	errNoGoroutine                = errors.New("no goroutine selected")
	errGoroutineNotRunning        = errors.New("selected goroutine not running")
	errNotEnoughStack             = errors.New("not enough stack space")
	errTooManyArguments           = errors.New("too many arguments")
	errNotEnoughArguments         = errors.New("not enough arguments")
	errNotAGoFunction             = errors.New("not a Go function")
	errFuncCallNotAllowedStrAlloc = errors.New("literal string can not be allocated because function calls are not allowed without using 'call'")
)

type functionCallState struct {
	// savedRegs contains the saved registers
	savedRegs Registers
	// err contains a saved error
	err error
	// expr is the expression being evaluated
	expr *ast.CallExpr
	// fn is the function that is being called
	fn *Function
	// receiver is the receiver argument for the function
	receiver *Variable

View on GitHub (pinned to a23773e6c3)

Solutions

Select the goroutine that is currently stopped at the breakpoint (the one hit by the debugger) before issuing 'call'
Check the goroutine's status with 'goroutines' and only call on status Running
If the interesting goroutine is blocked, use breakpoints/variable inspection instead of injecting calls

Example fix

// before: goroutine 5 is blocked on a channel
dlv> goroutine 5
dlv> call foo(1)
// after: use the running, stopped goroutine
dlv> goroutine 1
dlv> call foo(1)

Defensive patterns

Strategy: validation

Validate before calling

// only call on a Running goroutine stopped at a breakpoint
// dlv> goroutines   -- check status column is 'Running'
dlv> goroutine <running-id>
dlv> call foo(1)

Try / catch

if errors.Is(err, proc.ErrGoroutineNotRunning) {
    // re-select the goroutine stopped at the breakpoint and retry
}

Prevention

Check the goroutine status field before issuing 'call'
Use the goroutine that hit the breakpoint (scope of the current stop) for calls
For blocked goroutines, prefer breakpoints and variable inspection over call injection

When it happens

Trigger: Attempting a function call while the selected goroutine is blocked (chan receive, syscall, sleep) or parked; selecting a goroutine that is waiting rather than the one stopped at the breakpoint; 'call' issued after switching to a non-running goroutine.

Common situations: Switching to a goroutine blocked on I/O or channel ops and then trying 'call'; debugging a deadlocked program where no goroutine is running; picking the wrong goroutine ID after 'goroutines' listing.

Related errors

AI-assisted analysis of go-delve/delve@a23773e6c3 (2026-08-31). Data as JSON: /api/errors/416829321eea3ee2. Report an issue: GitHub.