What causes "breakpoint %d can not be enabled" in go-delve/delve?

Create breakpoints through the public SetBreakpoint/File:Line/FunctionName APIs so Set is populated

breakpoint %d can not be enabled

Error message

breakpoint %d can not be enabled

What it means

enableBreakpointOnTarget could not resolve any address source for the logical breakpoint: the breakpoint's Set spec had no File, FunctionName, PidAddrs, or Expr, so Delve has no way to compute where to place it. This indicates a LogicalBreakpoint constructed programmatically with an empty/unknown location spec, not a user-location problem.

Source

Thrown at pkg/proc/target_group.go:395

		return nil
	}
	var err error
	var addrs []uint64
	switch {
	case lbp.Set.File != "":
		addrs, err = FindFileLocation(p, lbp.Set.File, lbp.Set.Line)
	case lbp.Set.FunctionName != "":
		addrs, err = FindFunctionLocation(p, lbp.Set.FunctionName, lbp.Set.Line)
	case len(lbp.Set.PidAddrs) > 0:
		for _, pidAddr := range lbp.Set.PidAddrs {
			if pidAddr.Pid == p.Pid() {
				addrs = append(addrs, pidAddr.Addr)
			}
		}
	case lbp.Set.Expr != nil:
		addrs = lbp.Set.Expr(p)
	default:
		return fmt.Errorf("breakpoint %d can not be enabled", lbp.LogicalID)
	}

	if err != nil {
		return err
	}

	for _, addr := range addrs {
		_, err = p.SetBreakpoint(lbp.LogicalID, addr, UserBreakpoint, nil)
		if err != nil {
			if _, isexists := err.(BreakpointExistsError); isexists {
				continue
			}
			return err
		}
	}

	return err
}

View on GitHub (pinned to a23773e6c3)

Solutions

Create breakpoints through the public SetBreakpoint/File:Line/FunctionName APIs so Set is populated
Check that the location you passed (file, function name, or address) is non-empty and reached the LogicalBreakpoint
If restoring breakpoints from config, re-parse the location string instead of copying an empty Set
Log/inspect lbp.Set before enabling to confirm which field should carry the location

Example fix

// before
lbp := &proc.LogicalBreakpoint{LogicalID: id}
grp.SetBreakpointEnabled(lbp, true) // "breakpoint 5 can not be enabled"
// after
lbp.Set.File = "main.go"
lbp.Set.Line = 42
// or better: use the debugger-level API which parses the location for you
debugger.CreateBreakpoint(..., "main.go:42", ...)

Defensive patterns

Strategy: validation

Validate before calling

func validLocation(lbp *proc.LogicalBreakpoint) bool {
    s := lbp.Set
    return s.File != "" || s.FunctionName != "" || len(s.PidAddrs) > 0 || s.Expr != nil
}
// call before enabling: if !validLocation(lbp) { fix the Set spec }

Prevention

Always create breakpoints through APIs that populate LogicalBreakpoint.Set from a parsed location string
Never construct LogicalBreakpoint values directly with an empty Set
When restoring saved breakpoints, re-parse the original location string rather than deserializing a bare struct
Unit-test any code that builds breakpoints programmatically to assert Set is non-empty

When it happens

Trigger: Calling enableBreakpoint (via SetBreakpointEnabled(true), addTarget, pluginOpenCallback) on a LogicalBreakpoint whose Set struct has all fields zero-valued — e.g. a breakpoint deserialized from an RPC/API payload that dropped the location, or an internal breakpoint whose spec was never filled in.

Common situations: Custom tooling creating LogicalBreakpoint values directly via API instead of using SetBreakpoint with a parsed location; API clients (rpc2/DAP) sending empty location fields; version skew where a serialized breakpoint config no longer matches the struct.

Related errors

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