What causes "hardware breakpoints exhausted" in go-delve/delve?

Delete existing hardware breakpoints/watchpoints to free a slot before adding new ones.

hardware breakpoints exhausted

Error message

hardware breakpoints exhausted

What it means

ARM64 hardware breakpoints/watchpoints are a finite resource (the count is read from the HW debug registers via getWatchpoints, wpstate.num, typically 6 breakpoints / 4 watchpoints). writeHardwareBreakpoint refuses to program slot `idx` when idx >= wpstate.num, meaning all available hardware slots are exhausted or an invalid index was requested.

Source

Thrown at pkg/proc/native/threads_linux_arm64.go:152

		return nil, nil
	}

	for _, bp := range t.dbp.Breakpoints().M {
		if bp.WatchType != 0 && siginfo.addr >= bp.Addr && siginfo.addr < bp.Addr+uint64(bp.WatchType.Size()) {
			return bp, nil
		}
	}

	return nil, fmt.Errorf("could not find hardware breakpoint for address %#x", siginfo.addr)
}

func (t *nativeThread) writeHardwareBreakpoint(addr uint64, wtype proc.WatchType, idx uint8) error {
	wpstate, err := t.getWatchpoints()
	if err != nil {
		return err
	}
	if idx >= wpstate.num {
		return errors.New("hardware breakpoints exhausted")
	}

	const (
		readBreakpoint  = 0x1
		writeBreakpoint = 0x2
		lenBitOffset    = 5
		typeBitOffset   = 3
		privBitOffset   = 1
	)

	var typ uint64
	if wtype.Read() {
		typ |= readBreakpoint
	}
	if wtype.Write() {
		typ |= writeBreakpoint
	}

View on GitHub (pinned to a23773e6c3)

Solutions

Delete existing hardware breakpoints/watchpoints to free a slot before adding new ones.
Convert some watchpoints to software breakpoints (regular breakpoints) which are unlimited.
Check available hardware slots: `cat /proc/sys/debug/` or delve's watchpoint count on the target machine.
If more watchpoints are needed, use a machine/kernel with more debug registers or use page-protection-based alternatives.

Defensive patterns

Strategy: validation

Validate before calling

// query available hardware breakpoint slots before setting more
maxBp := readHWBreakpointCount() // e.g. from ID_AA64MDR0_EL1 / kernel, typically 6
if activeHWBreakpoints >= maxBp {
	return errors.New("no free hardware breakpoint slots")
}

Type guard

func isHWBreakpointsExhausted(err error) bool {
	return err != nil && strings.Contains(err.Error(), "hardware breakpoints exhausted")
}

Try / catch

err := dlv.CreateWatchpoint(addr, size, write)
if err != nil && strings.Contains(err.Error(), "hardware breakpoints exhausted") {
	// fall back to a software breakpoint
	return dlv.CreateBreakpoint(addr)
}

Prevention

Track how many hardware watchpoints (usually 4 on arm64) are active before adding more.
Remove unused hardware breakpoints/watchpoints promptly.
Fall back to software breakpoints when hardware slots run out.
Check the target CPU's debug-register count on constrained ARM hardware.

When it happens

Trigger: Setting a hardware breakpoint or watchpoint (writeHardwareBreakpoint) when the requested slot index exceeds the number of available hardware breakpoint registers reported by the kernel on arm64 Linux.

Common situations: Setting more hardware watchpoints than the CPU supports (commonly 4 on arm64); creating many `watch` commands with hardware backing; running on hardware with fewer debug registers (e.g. some ARM cores expose fewer).

Related errors

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