What causes "bad access" in go-delve/delve?

This is a real fault in the target: inspect the stopped goroutine's stack and variables to find the bad memory access.

bad access

Error message

bad access

What it means

machTargetExcToError maps Mach exception codes reported over the GDB remote protocol to Go errors. Code 0x91 (EXC_BAD_ACCESS) becomes 'bad access', meaning the process accessed invalid memory (the Go equivalent of a SIGSEGV).

Source

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

}

func (regs *gdbRegisters) Copy() (proc.Registers, error) {
	savedRegs := &gdbRegisters{}
	savedRegs.init(regs.regsInfo, regs.arch, regs.regnames)
	copy(savedRegs.buf, regs.buf)
	copy(savedRegs.loaded, regs.loaded)
	return savedRegs, nil
}

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
	}

View on GitHub (pinned to a23773e6c3)

Solutions

This is a real fault in the target: inspect the stopped goroutine's stack and variables to find the bad memory access.
Check for nil map/pointer use or out-of-bounds writes in the code at the stop location.
Increase stack limits if the access is a stack overflow (goroutine stacks grow, but cgo recursion can overflow).
If it appears without a real fault, check macOS version compatibility of lldb-server/delve.

Defensive patterns

Strategy: try-catch

Try / catch

if err != nil && strings.Contains(err.Error(), "bad access") {
    // target hit SIGSEGV; inspect stopped goroutine state
}

Prevention

Check pointers/maps for nil before dereferencing in debugged code.
Watch for stack-overflow-prone recursion (especially cgo).
Treat 'bad access' stops as real program faults, not debugger issues.

When it happens

Trigger: On macOS, the target receives a Mach exception with code 0x91 during a continue/wait; the gdbserial layer translates it into this error for the stop reason.

Common situations: Nil/invalid pointer dereference in the debugged program, stack overflow, or genuinely invalid memory access while debugging on macOS with the lldb backend.

Related errors

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