go-delve/delve · error

multiple errors evaluating conditions

Error message

multiple errors evaluating conditions

What it means

This error is built by conditionErrors (called from Continue) when, after a continue stops at breakpoints, more than one thread has a breakpoint whose condition failed to evaluate (bp.CondError != nil). Since only one condition error can be reported, delve replaces the ambiguity with this aggregate message so the user knows multiple conditional breakpoints are misbehaving.

Source

Thrown at pkg/proc/target_exec.go:348

func isTraceOrTraceReturn(bp *Breakpoint) bool {
	if bp.Logical == nil {
		return false
	}
	return bp.Logical.Tracepoint || bp.Logical.TraceReturn
}

func conditionErrors(grp *TargetGroup) error {
	var condErr error
	for _, dbp := range grp.targets {
		if isvalid, _ := dbp.Valid(); !isvalid {
			continue
		}
		for _, th := range dbp.ThreadList() {
			if bp := th.Breakpoint(); bp.Breakpoint != nil && bp.CondError != nil {
				if condErr == nil {
					condErr = bp.CondError
				} else {
					return errors.New("multiple errors evaluating conditions")
				}
			}
		}
	}
	return condErr
}

// pick a new dbp.currentThread, with the following priority:
//
//   - a thread with an active stepping breakpoint
//   - a thread with an active breakpoint, prioritizing trapthread
//   - trapthread if it is not nil
//   - the previous current thread if it still exists
//   - a randomly selected thread
func pickCurrentThread(dbp *Target, trapthread Thread) error {
	threads := dbp.ThreadList()
	for _, th := range threads {
		if bp := th.Breakpoint(); bp.Active && bp.Stepping {

View on GitHub (pinned to a23773e6c3)

Solutions

1. Fix or remove the condition on each breakpoint that errors (check breakpoint.CondError per breakpoint)
2. Validate condition expressions against variables in scope at the breakpoint
3. Temporarily remove conditions, confirm continues work, then re-add conditions one at a time
4. Use simpler conditions (literal comparisons on readable variables)

Example fix

// before
b.Breakpoint.Condition = "i > maxLimit" // maxLimit unreadable here
// after
b.Breakpoint.Condition = "i > 100"      // use in-scope variables/literals

// validate breakpoint conditions are simple and reference in-scope vars before continue
for _, bp := range bps {
    if bp.CondError != nil { fixCondition(bp) }
}

if err := grp.Continue(); err != nil && strings.Contains(err.Error(), "multiple errors evaluating conditions") {
    // inspect each thread's bp.CondError to find offending breakpoints
}

When it happens

Trigger: Continuing when two or more conditional breakpoints are hit and their AST conditions both raise evaluation errors (e.g. conditions referencing unreadable variables or invalid expressions).

Common situations: Breakpoints with conditions using variables out of scope at the breakpoint location; typos in condition expressions; evaluating conditions in optimized code where variables are unavailable.

Related errors

• condition expression unreadable: %v
• cannot write a breakpoint to a core file
• could not decode first frame
• unable to find function context
• unable to find locals: no debug information present in binar

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