go-delve/delve · error

error evaluating expression: %v

Error message

error evaluating expression: %v

What it means

Wrapped by evalBreakpointCondition (pkg/proc/breakpoints.go:515) when the AST expression of a conditional breakpoint fails during evaluation at a breakpoint hit (scope creation or compilation succeeded, but stack.eval/stack.result returned an error). Common inner causes: unreadable variables, out-of-scope variables, nil dereference, function-call evaluation errors. The breakpoint is then recorded as hit-with-error (CondError) and the condition is treated as not satisfied.

Source

Thrown at pkg/proc/breakpoints.go:515

		scope, err = ThreadScope(tgt, thread)
		if err != nil {
			return true, err
		}
	}
	flags := scope.evalopFlags()
	flags |= evalop.BreakpointCondition
	ops, err := evalop.CompileAST(scopeToEvalLookup{scope}, cond, flags)
	if err != nil {
		return true, err
	}
	stack := &evalStack{}
	stack.eval(scope, ops)
	v, err := stack.result(nil)
	if err != nil {
		if stack.disabledErrors {
			return false, nil
		}
		return true, fmt.Errorf("error evaluating expression: %v", err)
	}
	if v.Kind != reflect.Bool {
		if stack.disabledErrors {
			return false, nil
		}
		return true, errors.New("condition expression not boolean")
	}
	v.loadValue(LoadFullValue())
	if v.Unreadable != nil {
		if stack.disabledErrors {
			return false, nil
		}
		return true, fmt.Errorf("condition expression unreadable: %v", v.Unreadable)
	}
	return constant.BoolVal(v.Value), nil
}

// NoBreakpointError is returned when trying to

View on GitHub (pinned to a23773e6c3)

Solutions

1. Read the inner error after 'error evaluating expression:' — it names the failing sub-expression (undefined symbol, unreadable, etc.) and fix the condition accordingly.
2. Verify the variable exists and is in scope at the breakpoint location (`print var` at that breakpoint); move the breakpoint to a line where the variable is live.
3. Simplify the condition — avoid function calls, nil dereferences, and unsupported types; precompute into a local variable if possible.
4. Note that optimized Go code may make variables unreadable; rebuild with -gcflags='all=-N -l' for reliable condition evaluation.

Example fix

// before: condition evaluated where x may be out of scope or nil
break main.handler if x.Value == 42

// after: guard against nil / move breakpoint to a line where x is in scope
break main.handler if x != nil && x.Value == 42

// Before relying on a condition, evaluate it interactively at the breakpoint:
// dlv> break main.handler
// dlv> continue
// dlv> print x            // is the variable in scope and readable?
// dlv> condition 1 x != nil && x.Value == 42

// Caller-side (e.g. rpc2 client) handling:
_, err := client.Condition(bpID, "x.Value == 42")
// On hit, inspect breakpoint state / ConditionReturn instead of assuming success:
if st.CondError != nil && strings.Contains(st.CondError.Error(), "error evaluating expression") {
    // fix the condition expression, do not retry blindly
}

When it happens

Trigger: Setting a breakpoint condition (`break loc if expr` or Condition on rpc2/DAP) whose expression cannot be evaluated at the hit point: variable not in scope at that line, nil pointer in the expression, unreadable memory, unsupported call expressions, or errors from evalop.CompileAST-propagated evaluation.

Common situations: Condition referencing a variable declared later in the function or only in another branch, condition on a breakpoint hit in a frame where the variable was optimized out, evaluating map/chan/func values unsupported for printing, stale conditions after code changes shift lines.

Related errors

• internal error unknown breakpoint kind %v
• cannot write a breakpoint to a core file
• operations on non-finite floats not implemented
• shift count must not be negative
• multiple errors evaluating conditions

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