Use brk #0 as the fatal crash instruction on arm64 (macOS 26 kills brk #0xbb08 before a SIGTRAP handler runs) - #485
Conversation
|
Warning Review limit reached
On-demand reviews are free for the next 23 days. After that, they cost $0.25 per reviewed file. Or wait 18 minutes for your next included review. View limit detailsLimit details: You’ve used all 5 included reviews currently available. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 5 included reviews per hour; 0 remain after this review. WalkthroughChangesARM64 crash trap alignment
Windows ARM64 Scoop setup
Merge Risk: ⚪ Minimal · up to The PR changes the arm64 fatal crash instruction so failures can reach the crash handler on affected macOS systems; no actionable merge-blocking risk remains beyond normal checks and review. 🚥 Pre-merge checks | ✅ 3 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (3 passed)
Full details: Description checkExplanation The description provides a detailed, relevant explanation of the problem, fix, verification, scope, and related changes. However, it omits required template items, including a Bugzilla bug title and link, Warning Git: CodeRabbit could not clone the repository, so clone-backed analysis was skipped and this review may be incomplete. Verify repository clone access, such as SSH credentials, before requesting another full review. If clone access is intentionally unavailable, use Comment |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM — targeted change to the arm64 crash instruction immediate, gated on USE(BUN_JSC_ADDITIONS) and reusing the value the ASAN path already ships.
What was reviewed:
- Consumers of
WTF_FATAL_CRASH_CODE(MacroAssemblerARM64, offlineasm, LLInt spacer) — none compare against a specific immediate;ARM64Assembler::isBrkmasks the immediate out. - Remaining hardcoded
0xbb08in the tree — onlylibpas/pas_utils.c, which Bun does not compile underUSE_MIMALLOC. - The unconditional
BAssert.hedit — bmalloc has noUSE_BUN_JSC_ADDITIONSvisibility, and this is the Bun fork; the inline comment points back to the WTF rationale.
Extended reasoning...
Overview
The PR changes the arm64 fatal-crash instruction from brk #0xbb08 to brk #0 in two places: WTF_FATAL_CRASH_CODE/WTF_FATAL_CRASH_INST in wtf/Assertions.h (gated on USE(BUN_JSC_ADDITIONS), sharing the existing ASAN branch) and BBreakpointTrap() in bmalloc/BAssert.h (unconditional, since bmalloc does not see the Bun feature macro). The motivation is that macOS 26 SIGKILLs a process executing brk #0xbb08 before any SIGTRAP handler runs, defeating Bun's crash reporter.
Security risks
None. This only changes the 16-bit immediate encoded in the trap instruction that runs when the process is already about to die. It does not affect control flow, memory layout, or any input handling. brk #0 is already what the ASAN configuration and ARM64Assembler::align padding emit.
Level of scrutiny
Low-to-moderate. The macros feed every CRASH()/RELEASE_ASSERT site, so a mistake would break crash behavior broadly — but the change is a two-token edit to a preprocessor condition plus one string literal. I grepped for all consumers of WTF_FATAL_CRASH_CODE (MacroAssemblerARM64::breakpoint default arg, two inline-asm sites in MacroAssemblerARM64.cpp, the LLInt spacer, and offlineasm's break) and confirmed none of them care about the specific value. The only reader of the encoded instruction, ARM64Assembler::isBrk, masks the immediate via excepnGenerationImmMask() and matches any brk. The only remaining literal 0xbb08 in Source/ is in libpas, which Bun does not build.
Other factors
The WTF change preserves upstream behavior when USE_BUN_JSC_ADDITIONS is off, and simply adds Bun to the same #if branch ASAN already takes — so the value is already exercised in CI. The BAssert.h change is unconditional, but this is Bun's WebKit fork and the added comment cross-references the WTF header for rationale, keeping the divergence discoverable. The PR description documents manual verification (preprocessing a TU against the current cmakeconfig) and a companion Bun-side test. Given the small mechanical scope, clear gating, and absence of any code that depends on the old immediate, this is safe to approve without further human review.
Preview Builds
|
|
The bun side is oven-sh/bun#39978. It pins |
…brk #0 On macOS 26 arm64, brk #0xbb08 (the instruction behind WTF's CRASH() and RELEASE_ASSERT) kills the process before bun's SIGTRAP handler runs, so JSC, WTF and bun C++ assertion failures produced no crash report. The bumped engine emits brk #0 there. The new test makes JSC fail a RELEASE_ASSERT during initialization and expects a crash report on every POSIX platform.
1262c7b to
9b04f93
Compare
There was a problem hiding this comment.
LGTM — swaps the arm64 crash instruction's immediate to #0 under USE(BUN_JSC_ADDITIONS), matching the existing ASAN branch.
Checked that all JIT-side emitters (MacroAssemblerARM64::breakpoint, offlineasm break, LLInt spacer, ctiMasmProbeTrampoline) go through WTF_FATAL_CRASH_CODE and change together.
Confirmed ARM64Assembler::isBrk masks the immediate out via excepnGenerationImmMask(), so nothing depends on the 0xbb08 value.
Non-Bun builds keep the upstream 0xbb08; the unconditional bmalloc change is scoped to this fork and bmalloc doesn't see USE_BUN_JSC_ADDITIONS anyway.
Extended reasoning...
Overview
This PR changes two preprocessor macros that define the arm64 fatal-crash instruction:
Source/WTF/wtf/Assertions.h: adds|| USE(BUN_JSC_ADDITIONS)to the existingASAN_ENABLEDbranch soWTF_FATAL_CRASH_CODEbecomes0x0andWTF_FATAL_CRASH_INSTbecomes"brk #0x0"in Bun builds. Upstream builds without the flag still get0xbb08.Source/bmalloc/bmalloc/BAssert.h: changesBBreakpointTrap()on arm64 frombrk #0xbb08tobrk #0unconditionally (bmalloc has no visibility intoUSE_BUN_JSC_ADDITIONS, and this is Bun's fork).
The motivation is that macOS 26 SIGKILLs a process executing brk #0xbb08 before any SIGTRAP handler runs, so Bun's crash reporter never gets a chance to print anything. brk #0 is delivered as a normal SIGTRAP.
Security risks
None. The instruction still traps unconditionally; only the 16-bit immediate encoded in the brk opcode changes. Nothing in JSC decodes that immediate — I verified ARM64Assembler::isBrk masks it out with excepnGenerationImmMask(), and there are no other readers. The 0xbb08 value is purely a marker for Apple's crash reporter, which Bun doesn't use.
Level of scrutiny
Low. This is effectively a config-constant change gated behind a Bun-specific build flag, reusing values the ASAN configuration already ships with. All downstream users of the macro (MacroAssemblerARM64::breakpoint(), ctiMasmProbeTrampoline, offlineasm's break opcode, the LLInt begin-spacer) reference WTF_FATAL_CRASH_CODE and pick up the new value automatically. The bmalloc edit is a one-token change inside an #elif BCPU(ARM64) branch that only applies on Darwin/PlayStation release builds.
Other factors
The PR description is thorough and already enumerates the callers, the libpas copy that was intentionally left alone (compiled out under USE_MIMALLOC), and the preprocessor verification against Bun's shipped cmakeconfig.h. A companion test in oven-sh/bun#39978 forces a RELEASE_ASSERT failure on darwin-aarch64 CI to confirm the crash handler now runs. There are no outstanding reviewer comments and no prior automated review from me.
…brk #0 On macOS 26 arm64, brk #0xbb08 (the instruction behind WTF's CRASH() and RELEASE_ASSERT) kills the process before bun's SIGTRAP handler runs, so JSC, WTF and bun C++ assertion failures produced no crash report. The bumped engine emits brk #0 there. The new test makes JSC fail a RELEASE_ASSERT during initialization and expects a crash report on every POSIX platform.
9b04f93 to
1336a39
Compare
There was a problem hiding this comment.
LGTM — small, well-scoped constant change that reuses the values the ASAN branch already emits.
What was reviewed:
- Consumers of
WTF_FATAL_CRASH_CODE(MacroAssemblerARM64::breakpoint, LLInt spacer, offlineasm arm64.rb) — all just emitbrk #immat should-never-execute sites; the immediate value is irrelevant. ARM64Assembler::isBrkmasks out the immediate (& ~excepnGenerationImmMask()), so nothing decodes0xbb08specifically.- The unconditional bmalloc change is confined to the
NDEBUG && (DARWIN || PLAYSTATION)branch and only alters the trap immediate;brk #0still crashes.
Extended reasoning...
Overview
Two files touched: Source/WTF/wtf/Assertions.h widens two existing #if ASAN_ENABLED conditionals to ASAN_ENABLED || USE(BUN_JSC_ADDITIONS), so WTF_FATAL_CRASH_CODE becomes 0x0 and WTF_FATAL_CRASH_INST becomes "brk #0x0" in Bun builds on arm64. Source/bmalloc/bmalloc/BAssert.h changes bmalloc's arm64 BBreakpointTrap() from brk #0xbb08 to brk #0 (unconditionally, since bmalloc cannot see USE_BUN_JSC_ADDITIONS). Both changes add explanatory comments. The motivation — macOS 26 SIGKILLs on brk #0xbb08 before Bun's SIGTRAP handler runs — is well-documented in the PR body with a repro and .ips evidence.
Security risks
None. These macros define which arm64 trap instruction is emitted at intentional-crash sites (CRASH(), RELEASE_ASSERT, JIT breakpoint padding). Both brk #0 and brk #0xbb08 unconditionally trap; only the immediate operand differs, which affects how the OS classifies/delivers the exception, not whether the process halts. No auth, crypto, permission, or data-handling code is touched.
Level of scrutiny
Low. This is effectively a config-constant tweak that selects a value the codebase already ships under ASAN. The WTF change is gated behind USE(BUN_JSC_ADDITIONS), so upstream/non-Bun builds are unaffected. The bmalloc change is not gated, but (a) this is Bun's fork, (b) the branch is only reached under NDEBUG && (BOS(DARWIN) || BPLATFORM(PLAYSTATION)), and (c) the semantic difference is nil — the process still crashes, just with an immediate the kernel delivers as SIGTRAP rather than SIGKILL.
Other factors
I checked all consumers of WTF_FATAL_CRASH_CODE: MacroAssemblerARM64::breakpoint(), the two ctiMasmProbeTrampoline spacers in MacroAssemblerARM64.cpp, OFFLINE_ASM_BEGIN_SPACER in LowLevelInterpreter.cpp, and offlineasm/arm64.rb. All simply emit a brk with this immediate at unreachable/padding locations. ARM64Assembler::isBrk (the only decoder) explicitly masks out the 16-bit immediate before comparing, so it matches any brk. The PR description already covers the third copy in libpas/pas_utils.c (compiled out under USE_MIMALLOC). Preview builds for both commits succeeded, and the linked bun-side PR adds a cross-platform RELEASE_ASSERT crash test whose darwin-aarch64 lane exercises this path. No outstanding reviewer comments.
…brk #0 On macOS 26 arm64, brk #0xbb08 (the instruction behind WTF's CRASH() and RELEASE_ASSERT) kills the process before bun's SIGTRAP handler runs, so JSC, WTF and bun C++ assertion failures produced no crash report. The bumped engine emits brk #0 there. The new test makes JSC fail a RELEASE_ASSERT during initialization and expects a crash report on every POSIX platform.
1336a39 to
2cae530
Compare
There was a problem hiding this comment.
LGTM — swaps the arm64 crash-instruction immediate from 0xbb08 to 0x0 under USE(BUN_JSC_ADDITIONS) so macOS 26 delivers SIGTRAP instead of SIGKILL.
What was reviewed:
- Confirmed
ARM64Assembler::isBrkmasks the immediate out, so JIT breakpoint detection is unaffected. - Checked all consumers of
WTF_FATAL_CRASH_CODE(MacroAssemblerARM64, offlineasmbreak, LLInt spacer) — none depend on the specific value. - The bmalloc change is unconditional but only reached on Darwin/PlayStation release builds; libpas's copy is unused since Bun builds with mimalloc.
Extended reasoning...
Overview
This PR changes two preprocessor macros that define the arm64 crash instruction. In Source/WTF/wtf/Assertions.h, WTF_FATAL_CRASH_CODE and WTF_FATAL_CRASH_INST become 0x0 / "brk #0x0" when USE(BUN_JSC_ADDITIONS) is defined, joining the existing ASAN branch of the same #if. In Source/bmalloc/bmalloc/BAssert.h, BBreakpointTrap() is changed unconditionally from brk #0xbb08 to brk #0 (bmalloc has no access to the USE() macro). Both edits add a comment explaining why.
The motivation is that macOS 26 on arm64 sends SIGKILL (bypassing all signal handlers) when a process executes brk #0xbb08, so Bun's SIGTRAP-based crash reporter never runs. brk #0 is delivered as a normal SIGTRAP.
Security risks
None. The instruction still crashes the process; only the 16-bit immediate encoded in the brk opcode changes. There is no new attack surface, no data handling, and no control-flow change beyond which signal the kernel raises on an already-fatal path.
Level of scrutiny
Low. This is a constant tweak in crash-path macros, guarded by the fork-specific USE(BUN_JSC_ADDITIONS) flag for WTF (upstream behavior is preserved when the flag is off). I grepped for every consumer of WTF_FATAL_CRASH_CODE and 0xbb08: MacroAssemblerARM64::breakpoint() uses it as a default arg to brk, the PAC-failure paths in MacroAssemblerARM64.cpp and offlineasm's break emit it as inline asm, and LowLevelInterpreter.cpp uses it as a never-executed spacer. ARM64Assembler::isBrk explicitly masks the immediate (excepnGenerationImmMask()), so nothing in the JIT decodes or matches on the specific value. The libpas copy in pas_utils.c is left as-is, which the PR description justifies (Bun builds with USE_MIMALLOC, so LIBPAS_ENABLED is 0 and that file compiles to nothing).
Other factors
The PR description is thorough — it includes a preprocessor verification against Bun's shipped cmakeconfig.h, an .ips crash-report analysis confirming the SIGKILL behavior, and a survey of alternatives. A companion PR (oven-sh/bun#39978) adds a test that exercises RELEASE_ASSERT on darwin-aarch64 CI. Preview builds have completed for three revisions. The bmalloc change being unconditional is a minor divergence from upstream, but this is a fork and the comment points readers back to the WTF rationale.
…brk #0 On macOS 26 arm64, brk #0xbb08 (the instruction behind WTF's CRASH() and RELEASE_ASSERT) kills the process before bun's SIGTRAP handler runs, so JSC, WTF and bun C++ assertion failures produced no crash report. The bumped engine emits brk #0 there. The new test makes JSC fail a RELEASE_ASSERT during initialization and expects a crash report on every POSIX platform.
2cae530 to
eb06812
Compare
There was a problem hiding this comment.
LGTM — swaps the arm64 crash immediate from 0xbb08 to 0x0 under USE(BUN_JSC_ADDITIONS), matching the existing ASAN branch.
What was reviewed:
- Consumers of
WTF_FATAL_CRASH_CODE(MacroAssemblerARM64,LowLevelInterpreter.cpp, offlineasmarm64.rb) only emit the value; none compare against a fixed immediate. ARM64Assembler::isBrkmasks the immediate out, so it recognisesbrk #0unchanged.- The unconditional
BAssert.hchange is fine for this fork; the remainingpas_utils.ccopy is dead whenBENABLE_LIBPASis 0 as the description notes.
Extended reasoning...
Overview
Two-file change to the arm64 fatal-crash instruction. In Source/WTF/wtf/Assertions.h, the CPU(ARM64) branch of WTF_FATAL_CRASH_CODE / WTF_FATAL_CRASH_INST gains || USE(BUN_JSC_ADDITIONS) alongside the existing ASAN_ENABLED guard, selecting brk #0x0 instead of upstream's brk #0xbb08. In Source/bmalloc/bmalloc/BAssert.h, the standalone BBreakpointTrap() copy for BCPU(ARM64) is changed to brk #0 unconditionally (bmalloc has no visibility into the Bun feature macro), with a comment pointing at the WTF definition. A three-line explanatory comment is added above the WTF macros.
Security risks
None. The change only alters the 16-bit immediate of a trap instruction that is already a deliberate, unrecoverable crash. No new control flow, no data handling, no trust-boundary changes. On Linux both immediates deliver SIGTRAP identically; on macOS 26 the new immediate lets Bun's SIGTRAP handler run instead of the kernel SIGKILLing the process — strictly a diagnostics improvement.
Level of scrutiny
Low. The WTF change piggybacks on an existing, upstream-maintained branch (ASAN_ENABLED already selects the same 0x0 values), so the code path is already exercised. I checked every reader of WTF_FATAL_CRASH_CODE in the tree: MacroAssemblerARM64::breakpoint(), the PAC-auth-failure traps in MacroAssemblerARM64.cpp, the LLInt begin-spacer, and offlineasm's break opcode all just emit the value — none decode or match against a specific immediate. ARM64Assembler::isBrk explicitly masks the immediate out via excepnGenerationImmMask(), so instruction recognition is unaffected. The remaining hard-coded 0xbb08 in libpas/pas_utils.c is compiled out when BENABLE_LIBPAS is 0 (Bun uses mimalloc), as the PR description documents.
Other factors
The unconditional bmalloc edit is acceptable in this fork: it only affects the release-mode Darwin/PlayStation BCRASH() path, and brk #0 is a valid trap on every arm64 target. Preview builds are green across all four revisions, and a companion test in oven-sh/bun#39978 exercises the darwin-aarch64 lane. No prior human review comments are outstanding.
…brk #0 On macOS 26 arm64, brk #0xbb08 (the instruction behind WTF's CRASH() and RELEASE_ASSERT) kills the process before bun's SIGTRAP handler runs, so JSC, WTF and bun C++ assertion failures produced no crash report. The bumped engine emits brk #0 there. The new test makes JSC fail a RELEASE_ASSERT during initialization and expects a crash report on every POSIX platform.
eb06812 to
5cd9ee3
Compare
…brk #0 On macOS 26 arm64, brk #0xbb08 (the instruction behind WTF's CRASH() and RELEASE_ASSERT) kills the process before bun's SIGTRAP handler runs, so JSC, WTF and bun C++ assertion failures produced no crash report. The bumped engine emits brk #0 there. The new test makes JSC fail a RELEASE_ASSERT during initialization and expects a crash report on every POSIX platform.
5cd9ee3 to
28b4464
Compare
…brk #0 On macOS 26 arm64, brk #0xbb08 (the instruction behind WTF's CRASH() and RELEASE_ASSERT) kills the process before bun's SIGTRAP handler runs, so JSC, WTF and bun C++ assertion failures produced no crash report. The bumped engine emits brk #0 there. The new test makes JSC fail a RELEASE_ASSERT during initialization and expects a crash report on every POSIX platform.
28b4464 to
3a8e5d1
Compare
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
|
The Preview Build of this branch was failing on the |
…brk #0 On macOS 26 arm64, brk #0xbb08 (the instruction behind WTF's CRASH() and RELEASE_ASSERT) kills the process before bun's SIGTRAP handler runs, so JSC, WTF and bun C++ assertion failures produced no crash report. The bumped engine emits brk #0 there. The new test makes JSC fail a RELEASE_ASSERT during initialization and expects a crash report on every POSIX platform.
c3bf2c7 to
d12dc20
Compare
…brk #0 On macOS 26 arm64, brk #0xbb08 (the instruction behind WTF's CRASH() and RELEASE_ASSERT) kills the process before bun's SIGTRAP handler runs, so JSC, WTF and bun C++ assertion failures produced no crash report. The bumped engine emits brk #0 there. The new test makes JSC fail a RELEASE_ASSERT during initialization and expects a crash report on every POSIX platform.
…brk #0 On macOS 26 arm64, brk #0xbb08 (the instruction behind WTF's CRASH() and RELEASE_ASSERT) kills the process before bun's SIGTRAP handler runs, so JSC, WTF and bun C++ assertion failures produced no crash report. The bumped engine emits brk #0 there. The new test makes JSC fail a RELEASE_ASSERT during initialization and expects a crash report on every POSIX platform.
d12dc20 to
b3c7ff9
Compare
…brk #0 On macOS 26 arm64, brk #0xbb08 (the instruction behind WTF's CRASH() and RELEASE_ASSERT) kills the process before bun's SIGTRAP handler runs, so JSC, WTF and bun C++ assertion failures produced no crash report. The bumped engine emits brk #0 there. The new test makes JSC fail a RELEASE_ASSERT during initialization and expects a crash report on every POSIX platform.
b3c7ff9 to
55036de
Compare
55036de to
ccdf49f
Compare
…brk #0 On macOS 26 arm64, brk #0xbb08 (the instruction behind WTF's CRASH() and RELEASE_ASSERT) kills the process before bun's SIGTRAP handler runs, so JSC, WTF and bun C++ assertion failures produced no crash report. The bumped engine emits brk #0 there. The new test makes JSC fail a RELEASE_ASSERT during initialization and expects a crash report on every POSIX platform.
On macOS 26, a process that executes brk #0xbb08 is killed with SIGKILL before its SIGTRAP handler runs. Bun's crash handler is a SIGTRAP handler, so every CRASH(), RELEASE_ASSERT and JIT breakpoint() on arm64 macOS died without a crash report. Under USE(BUN_JSC_ADDITIONS), WTF_FATAL_CRASH_CODE is 0 and WTF_FATAL_CRASH_INST is "brk #0x0", the values the ASAN configuration already uses. bmalloc's BBreakpointTrap() uses brk #0 as well.
ccdf49f to
c9ed924
Compare
…brk #0 On macOS 26 arm64, brk #0xbb08 (the instruction behind WTF's CRASH() and RELEASE_ASSERT) kills the process before bun's SIGTRAP handler runs, so JSC, WTF and bun C++ assertion failures produced no crash report. The bumped engine emits brk #0 there. The new test makes JSC fail a RELEASE_ASSERT during initialization and expects a crash report on every POSIX platform.
1 participant
Problem
RELEASE_ASSERTorCRASH()in bun ends inKilled: 9with an empty stderr. Repro:BUN_JSC_structureHeapSizeInKB=3072 bun -e 1(StructureAlignedMemoryAllocator.cpp:110). Linux and macOS x64 print a crash report.WTF_FATAL_CRASH_INST(wtf/Assertions.h:291) isbrk #0xbb08, and macOS 26 kills the process on that immediate before it delivers SIGTRAP. A C program with a SIGTRAP handler dies the same way onbrk #0xbb08and runs its handler onbrk #0. Crashes after startup die too: JSC owns a Mach port forEXC_BAD_ACCESSonly.Fix
USE(BUN_JSC_ADDITIONS),WTF_FATAL_CRASH_CODEis0x0andWTF_FATAL_CRASH_INSTis"brk #0x0", the values the ASAN branch of the same#ifalready uses. bmalloc'sBBreakpointTrap()has its own copy and gets the same value, unconditionally, since bmalloc does not seeUSE_BUN_JSC_ADDITIONS.ARM64Assembler::isBrk, the one reader of the instruction, masks the immediate out. The upstream values stay when the option is off.brk #0is delivered as SIGTRAP on the macOS 26 CI machines: bun's trap test hook executes it and is reported. Verified with the preprocessor against bun's prebuiltcmakeconfig.h(Notes). The bun side (pin bump and test) is Bump WebKit (oven-sh/WebKit#485 preview): JSC and WTF crashes on macOS 26 arm64 reach the crash handler again bun#39978.Background
RELEASE_ASSERTin a release build isCRASH_WITH_INFO(): on Darwin an inlineasmofWTF_FATAL_CRASH_INSTwith the line number in x0, on other platformsabort().src/crash_handlerin oven-sh/bun) is asigactionhandler for SIGTRAP and the other fatal signals. A SIGKILL from the kernel bypasses it.Notes
Preprocessor check, using the
cmakeconfig.hshipped in bun's current prebuilt (b7f217b4a6): a TU that includes this header expandsWTF_FATAL_CRASH_INSTto"brk #0x0"andWTF_FATAL_CRASH_CODEto0x0with this change, to"brk #0xbb08"/0xbb08without it, and to the upstream values withUSE_BUN_JSC_ADDITIONSset to 0. Forcing ASAN on gives the same values as before.The
.ipsreport of the killed bun process (macOS 26.6.2,structureHeapSizeInKB=32768, which fails the assert at:147): exception typeEXC_BREAKPOINT, esr descriptionbrk 47880(0xbb08), signal SIGKILL, x0 = 0x93 = 147, the faulting thread inside theJSC::initializecall_oncechain with no signal handler frames on top. The C program usedSA_SIGINFO, with and withoutSA_ONSTACK. bun's own trap hook (brk #0) is why bun's crash handler tests pass on the same machines.libpas has a third copy of the instruction (
pas_utils.c), left alone: bun's builds setUSE_MIMALLOC,BPlatform.hthen leavesBENABLE_LIBPASat 0, andpas_config.hturnsLIBPAS_ENABLEDoff, so the file compiles to nothing. Nothing decodes the immediate:ARM64Assembler::isBrkmasks it out and has no callers, VM traps and Wasm faults are access faults (replaceWithVMHaltemitsdc zva xzr) identified by PC, LLInt code is recognised by address range (LLIntPCRanges.h), and the disassembler prints anybrk.LinkBufferpads withbreakpoint()andARM64Assembler::alignwithbrk #0, both never executed.The change applies to every arm64 target, not only Darwin. On Linux
brk #0andbrk #0xbb08are both a SIGTRAP, and one value keeps bun's trap hook and WTF's crash sites identical everywhere.Alternatives:
CRASH()asabort()on Darwin would also work (bun handles SIGABRT) but moves frame 0 of every report from the assert intoabort()and diverges further from upstream. A Mach exception port forEXC_BREAKPOINTin bun would be much more code for the same result.Apple's crash reporter gives
brk 0xbb08a meaning (WebKit's fatal crash marker). Bun uploads its own reports, so the marker has no value for bun.