Dev 3.0 v1.13.0 crashes immediately on launch with a segmentation fault. The Electrobun self-extractor (v1.3) never completes extraction.

[AlexanderVase]

Environment:

• MacBook Pro 2019 (MacBookPro15,4)
• Quad-Core Intel Core i5, 1.4 GHz
• 8 GB RAM
• macOS 15.7.5 (24G624)
• Code Type: X86-64 (Native)

Steps to reproduce:

1. Download and install dev-3.0.app to /Applications
2. Launch the app (either via Finder or terminal)

Terminal output:
$ /Applications/dev-3.0.app/Contents/MacOS/launcher
Electrobun self-extractor v1.3 starting...
zsh: segmentation fault /Applications/dev-3.0.app/Contents/MacOS/launcher

Crash details:

• Exception: EXC_BAD_ACCESS (SIGSEGV) — KERN_INVALID_ADDRESS at 0x00000000ff39b6d5
• Crashed in: fs.path.resolve + 5 → main.main + 301
• The self-extractor crashes before any extraction occurs, suggesting it fails to resolve the target path.

Attempted fixes (none worked):

• Removed quarantine flag (xattr -rd com.apple.quarantine)
• Verified sufficient disk space
• Re-downloaded the app

Hypothesis:
The fs.path.resolve function in the launcher dereferences an invalid pointer on x86-64. This may be an Intel-specific code path issue in
Electrobun's self-extractor, or an alignment/memory layout difference compared to ARM64.

[h0x91b]

Hi @AlexanderVase — Claude here, the AI assistant working on this branch. Thanks a lot for the very detailed report — the symbol offsets and the environment info made the investigation much easier. Quick recap of where we've ended up, in case anyone (future me included) picks this back up.

What's actually crashing

The launcher binary inside dev-3.0.app/Contents/MacOS/ is the Electrobun "self-extractor v1.3" — a small Zig binary shipped as-is in Electrobun's electrobun-core-darwin-x64.tar.gz (v1.18.1). We just code-sign it and put it in the bundle. The shipped binary is byte-identical to upstream extractor from blackboardsh/electrobun v1.18.1, except for the codesign envelope. We adopted Electrobun 1.18.1 in dev-3.0 v1.13.0 (PR #549), so this is the first dev-3.0 release with this particular self-extractor.

From the symbol offsets in your crash report:

• fs.path.resolve + 5 lands on the 4th push %r13 in the function's prologue (the very first thing it does is push six callee-saved registers).
• main.main + 301 (= 0x12D) is the return address right after the CALL _fs.path.resolve in main.main.

So the binary dies the first time main.main calls fs.path.resolve — right after it printed Electrobun self-extractor v1.3 starting... and resolved its own executable path via realpath. The faulting instruction itself is just a register push (no fancy SSE/AVX or anything CPU-specific).

Why this is weird

The faulting address 0x00000000ff39b6d5 is below 0x100000000, which is the top of __PAGEZERO on x86_64 Mach-O binaries — that region is always unmapped. Walking back through main.main's ~275 KB stack frame (subq $0x449b8, %rsp), the only way for that push to land there is if %rsp was already extremely close to (or inside) PAGEZERO at the moment main.main started running. On a normal macOS x86_64 process the main thread stack is typically placed well above PAGEZERO and has 8 MB of headroom, so this is atypical and probably points at some macOS / dyld stack-placement edge case specific to your CPU+OS combination.

What we ruled out

• Not a CPU baseline / non-baseline instruction issue. The Mach-O is CPU_SUBTYPE_X86_ALL, the offending instruction is a plain push, and the exception is SIGSEGV/KERN_INVALID_ADDRESS, not SIGILL (which is what a missing instruction-set extension would raise).
• Not a Bun-AVX issue. The crash happens in the self-extractor before Bun is ever spawned.
• Not something we mis-package on our side. The shipped binary matches upstream byte-for-byte modulo the codesign envelope, and it's the correct architecture (Mach-O 64-bit executable x86_64, Code Type: X86-64 (Native) as you observed).
• Not Rosetta-specific. We ran the same shipped x86_64 binary on an Apple Silicon machine under Rosetta and it printed the banner and exited cleanly, so the binary contents themselves are good.

Relevant upstream lead

There's an open lead in the Electrobun repo with the exact same crash signature: blackboardsh/electrobun#415 ("x86_64 macOS launcher crashes with SIGSEGV in fs.path.resolve"). The reporter there also opened a PR to fix it (blackboardsh/electrobun#416, "Fix x86_64 launcher SIGSEGV by adding -Dcpu=baseline") — and then closed both the issue and the PR themselves with a note saying "launcher is already baseline, the issue is in my app's pipeline" — without disclosing what they actually changed on their side. That's where our trail goes cold without more data.

What would help us go further

I don't have an Intel Mac and can't reproduce this locally — under Rosetta the binary runs fine, so the bug appears specific to native x86_64 on certain macOS Sequoia / Intel combinations. If you have a minute (no pressure — what you already gave us was very useful), the things that would unlock further investigation are:

1. The full .ips crash report. It lives in ~/Library/Logs/DiagnosticReports/ — look for a file whose name starts with launcher- and ends in .ips. You can drag it directly into a comment here, or paste the contents. The full thread state (%rsp, %rip, register dump, binary image list) would let us check the PAGEZERO theory and rule a few other possibilities in or out.
2. Exact macOS build: sw_vers -buildVersion (you mentioned 24G624 already — just confirming).
3. Exact CPU string: sysctl -n machdep.cpu.brand_string and sysctl -n machdep.cpu.features (the second one shows the full instruction-set feature flags, AVX/AVX2/etc.).

If any other Intel Mac users are reading this and hitting (or not hitting) the same crash on v1.13.0+ — please drop a quick note here too. Right now this is the only Intel report we have, and we don't have visibility into how widespread it is.

Marking this needs clarification for now. The triage notes (offsets, disassembly, stack math, upstream pointers) are all here so we can pick it up again whenever fresh data lands or someone gets hands on an Intel machine to reproduce.

— Claude (AI assistant)