{"record":{"id":"5e1d8786823587b5","repo":"go-delve/delve","slug":"breakpoint-exception","errorCode":null,"errorMessage":"breakpoint exception","messagePattern":"breakpoint exception","errorType":"exception","errorClass":null,"httpStatus":null,"severity":"error","filePath":"pkg/proc/gdbserial/gdbserver.go","lineNumber":2235,"sourceCode":"func registerName(arch *proc.Arch, regNum uint64) string {\n\tregName, _, _ := arch.DwarfRegisterToString(int(regNum), nil)\n\treturn strings.ToLower(regName)\n}\n\nfunc machTargetExcToError(sig uint8) error {\n\tswitch sig {\n\tcase 0x91:\n\t\treturn errors.New(\"bad access\")\n\tcase 0x92:\n\t\treturn errors.New(\"bad instruction\")\n\tcase 0x93:\n\t\treturn errors.New(\"arithmetic exception\")\n\tcase 0x94:\n\t\treturn errors.New(\"emulation exception\")\n\tcase 0x95:\n\t\treturn errors.New(\"software exception\")\n\tcase 0x96:\n\t\treturn errors.New(\"breakpoint exception\")\n\t}\n\treturn nil\n}\n\nfunc checkRosettaExpensive() error {\n\tif runtime.GOOS != \"darwin\" {\n\t\treturn nil\n\t}\n\tif runtime.GOARCH != \"arm64\" {\n\t\treturn nil\n\t}\n\n\t// Additionally check the output of 'uname -m' if it's x86_64 it means that\n\t// the shell we are running on is being emulated by Rosetta even though our\n\t// process isn't. In this condition debugserver will crash.\n\tout, err := exec.Command(\"uname\", \"-m\").Output()\n\tif err != nil {\n\t\treturn nil","sourceCodeStart":2217,"sourceCodeEnd":2253,"githubUrl":"https://github.com/go-delve/delve/blob/a23773e6c31361e43246bc43a424ee009679b174/pkg/proc/gdbserial/gdbserver.go#L2217-L2253","documentation":"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.","triggerScenarios":"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.","commonSituations":"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.","solutions":["Examine the stopped thread's signal/PC and the goroutine stack to identify the runtime fatal error that triggered the trap","Check runtime error messages printed by the process (e.g. 'fatal error:' output) to find the root cause","Remove any foreign breakpoints or debuggers attached to the same process","If it is a genuine breakpoint hit, continue or clear the breakpoint via the Delve UI instead of treating it as a crash"],"exampleFix":null,"handlingStrategy":"try-catch","validationCode":null,"typeGuard":null,"tryCatchPattern":"if err := sess.Continue(); err != nil {\n    if strings.Contains(err.Error(), \"breakpoint exception\") {\n        // EXC_BREAKPOINT: inspect runtime 'fatal error' output and stack\n        state, _ := sess.GetState()\n        log.Printf(\"EXC_BREAKPOINT stop: %+v\", state)\n    }\n}","preventionTips":["Check process stderr for Go runtime 'fatal error:' messages to identify the trap source","Don't attach other debuggers that also insert breakpoint instructions","Test on a recent macOS/debugserver combination"],"tags":["gdbserial","macos","mach-exception","breakpoint"],"backgroundTag":"mach-exception-stop","analyzedSha":"a23773e6c31361e43246bc43a424ee009679b174","analyzedAt":"2026-08-31T15:12:45.221Z","schemaVersion":2},"datasetVersion":"2026-08-31T19:17:28.585Z"}