go-delve/delve · error

internal error unknown breakpoint kind %v

Error message

internal error unknown breakpoint kind %v

What it means

Set as bpstate.CondError in checkCond (pkg/proc/breakpoints.go:350) when a breakpoint's Breaklet.Kind does not match any known kind in the switch. This is an internal invariant violation: every Breaklet created by Delve must have a recognized Kind (UserBreakpoint, stepping kinds, watch/scope kinds, etc.). A user of the library only sees it if Delve itself is inconsistent or if internal breakpoint kinds were fabricated incorrectly.

Source

Thrown at pkg/proc/breakpoints.go:350

		active = active && nextDeferOk

	case WatchOutOfScopeBreakpoint:
		if breaklet.checkPanicCall {
			frames, err := ThreadStacktrace(tgt, thread, 2)
			if err == nil {
				ipc, _ := isPanicCall(frames)
				active = active && ipc
			}
		}

	case StackResizeBreakpoint, PluginOpenBreakpoint, StepIntoNewProcBreakpoint, StepIntoRangeOverFuncBodyBreakpoint, SharedLibBreakpoint:
		// no further checks

	case NextInactivatedBreakpoint:
		active = false

	default:
		bpstate.CondError = fmt.Errorf("internal error unknown breakpoint kind %v", breaklet.Kind)
	}

	if active {
		if breaklet.callback != nil {
			var err error
			active, err = breaklet.callback(thread, tgt)
			if err != nil && bpstate.CondError == nil {
				bpstate.CondError = err
			}
		}
		bpstate.Active = active
	}

	if bpstate.Active {
		switch breaklet.Kind {
		case NextBreakpoint, NextDeferBreakpoint:
			bpstate.Stepping = true
		case StepBreakpoint:

View on GitHub (pinned to a23773e6c3)

Solutions

1. Upgrade Delve to the latest version — if reproducible on a released version, it is a bug.
2. Search the Delve source for where the offending Kind value is created and add a corresponding case in checkCond (pkg/proc/breakpoints.go:308-351).
3. Reproduce with a minimal scenario and file a Delve issue including the kind value printed in the message.
4. As a workaround, avoid the feature that creates the exotic breakpoint (e.g. specific stepping modes) until fixed.

Example fix

// before: new kind added but unhandled in checkCond
case StackResizeBreakpoint, PluginOpenBreakpoint, StepIntoNewProcBreakpoint:
    // no further checks

// after: include the new kind in the handled set
case StackResizeBreakpoint, PluginOpenBreakpoint, StepIntoNewProcBreakpoint, MyNewBreakpointKind:
    // no further checks

// Library-side sanity check before hitting evaluation:
for _, bl := range bp.Breaklets {
    if bl.Kind&(UserBreakpoint|StepBreakpoint|NextBreakpoint|NextDeferBreakpoint|
        WatchOutOfScopeBreakpoint|StackResizeBreakpoint|PluginOpenBreakpoint|
        StepIntoNewProcBreakpoint|StepIntoRangeOverFuncBodyBreakpoint|
        SharedLibBreakpoint|NextInactivatedBreakpoint) == 0 {
        panic(fmt.Sprintf("unhandled breakpoint kind %v", bl.Kind))
    }
}

When it happens

Trigger: A Breaklet whose Kind value is not handled by the switch in checkCond reaches breakpoint hit evaluation (checkCondition -> checkCond), e.g. after adding a new breakpoint kind without updating checkCond, bit-flag combinations of stepping kinds that don't match any case, or memory corruption of the Breakpoint struct.

Common situations: Running a development/patched Delve with a newly added breakpoint kind that forgot the checkCond case; combining breaklet kinds (they are bit flags) into an unhandled composite value; bugs fixed in newer Delve releases.

Related errors

• error evaluating expression: %v
• cannot write a breakpoint to a core file
• multiple errors evaluating conditions
• breakpoint already exists
• unable to set breakpoint

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