go-delve/delve · error

breakpoint exception

Error message

breakpoint exception

What it means

machTargetExcToError maps Mach exception code 0x96 (EXC_BREAKPOINT) to this error. The debuggee process hit a breakpoint-style Mach exception: either a deliberate trap instruction (int3/bkpt/trap) or a runtime-integrity check (e.g. Swift/Go runtime fatal traps use EXC_BREAKPOINT on macOS). Delve reports it as a stop reason so it can distinguish real breakpoints from runtime aborts.

Source

Thrown at pkg/proc/gdbserial/gdbserver.go:2235

func registerName(arch *proc.Arch, regNum uint64) string {
	regName, _, _ := arch.DwarfRegisterToString(int(regNum), nil)
	return strings.ToLower(regName)
}

func machTargetExcToError(sig uint8) error {
	switch sig {
	case 0x91:
		return errors.New("bad access")
	case 0x92:
		return errors.New("bad instruction")
	case 0x93:
		return errors.New("arithmetic exception")
	case 0x94:
		return errors.New("emulation exception")
	case 0x95:
		return errors.New("software exception")
	case 0x96:
		return errors.New("breakpoint exception")
	}
	return nil
}

func checkRosettaExpensive() error {
	if runtime.GOOS != "darwin" {
		return nil
	}
	if runtime.GOARCH != "arm64" {
		return nil
	}

	// Additionally check the output of 'uname -m' if it's x86_64 it means that
	// the shell we are running on is being emulated by Rosetta even though our
	// process isn't. In this condition debugserver will crash.
	out, err := exec.Command("uname", "-m").Output()
	if err != nil {
		return nil

View on GitHub (pinned to a23773e6c3)

Solutions

1. Examine the stopped thread's signal/PC and the goroutine stack to identify the runtime fatal error that triggered the trap
2. Check runtime error messages printed by the process (e.g. 'fatal error:' output) to find the root cause
3. Remove any foreign breakpoints or debuggers attached to the same process
4. If it is a genuine breakpoint hit, continue or clear the breakpoint via the Delve UI instead of treating it as a crash

if err := sess.Continue(); err != nil {
    if strings.Contains(err.Error(), "breakpoint exception") {
        // EXC_BREAKPOINT: inspect runtime 'fatal error' output and stack
        state, _ := sess.GetState()
        log.Printf("EXC_BREAKPOINT stop: %+v", state)
    }
}

When it happens

Trigger: Debugging on macOS with the gdbserial backend; the target thread stops with debugServerTargetExcBreakpoint (0x96) while continuing or stepping — for example a Go runtime fatal error (goexit traps, out-of-bounds with runtime check), or a breakpoint instruction in code not inserted by Delve.

Common situations: Go program panics with a runtime fault whose trap maps to EXC_BREAKPOINT on darwin; user sets breakpoints through another debugger simultaneously; debugging race/asan-instrumented binaries that trap deliberately.

Related errors

• bad access
• bad instruction
• emulation exception
• software exception
• could not find watchpoint at address %#x

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