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

Inspect where the PC stopped; verify the binary matches the host architecture (build with correct GOARCH).

bad instruction

Error message

bad instruction

What it means

machTargetExcToError maps Mach exception 0x92 (EXC_BAD_INSTRUCTION) to 'bad instruction', meaning the CPU executed an illegal/undefined instruction (equivalent of SIGILL).

Source

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

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
	}
	if runtime.GOARCH != "arm64" {
		return nil

View on GitHub (pinned to a23773e6c3)

Solutions

Inspect where the PC stopped; verify the binary matches the host architecture (build with correct GOARCH).
Rebuild the target binary; a truncated/corrupt build can produce illegal instructions.
Check for cgo/assembly bugs jumping into non-code memory.
If using Rosetta/emulation, test natively to isolate translation issues.

Defensive patterns

Strategy: try-catch

Try / catch

if err != nil && strings.Contains(err.Error(), "bad instruction") {
    // target hit SIGILL; check PC and binary arch
}

Prevention

Build the target with the correct GOARCH for the host.
Rebuild binaries if code pages may be corrupt.
Avoid hand-written assembly bugs that jump into data.

When it happens

Trigger: Target process on macOS executes an illegal opcode and the stub reports Mach exception code 0x92; delve converts it to this error as the stop reason.

Common situations: Executing corrupted code pages, jumping to data, architecture-mismatched binaries (e.g. x86 binary under ARM via bad translation), or deliberate UD2 traps in runtime assertions.

Related errors

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