anomalyco / anomalyco/opencode
SIGBUS (fatal signal 7) on Worker thread mid-stream, identical RIP 0x4248ec9 across 1.18.15/1.18.21 (bundled Bun 1.3.14), WSL2
@Hona is already working on this.
Since Aug 24, 2026.
- Dominant language
- TypeScript
- Stars
- 209k
- Forks
- 27.5k
- PR merge metrics
- PR metrics pending
Description
Description
opencode crashes with SIGBUS a few times a day while it is receiving a model response. The kernel log shows:
opencode.exe: Worker: potentially unexpected fatal signal 7.
After the crash the process is gone; my supervisor restarts it and I resend the prompt. It happened 3 times today (10:34, 12:38, 16:30 local). It seems to happen when the model response being streamed is long.
What I checked so far:
- Same crash on 1.18.15 (twice) and 1.18.21 (once). Both bundle Bun v1.3.14, and the faulting instruction address is the same every time (0x4248ec9), so it looks like one deterministic bug rather than random memory corruption.
- Not OOM / not WSL memory reclaim: plenty of free memory at crash time, swap untouched, and it still crashed after I set
autoMemoryReclaim=disabledand restarted WSL. - No disk I/O errors in dmesg; binary is a clean npm install.
- The faulting instruction is a UTF-16 string scan (
movzwl (%rdx,%rdi,2)). From the register dump, RDX points exactly one past the end of a page-aligned 16 KiB buffer while the scan loop uses it as its base. Happy to send the full disassembly / register dump if useful.
Plugins
None.
OpenCode version
1.18.21 (also seen on 1.18.15)
Steps to reproduce
Not fully deterministic on demand, but it reproduces several times per day in my setup:
- Run opencode TUI on WSL2 (Ubuntu, ext4 root).
- Ask it to do agent work that produces a long streamed response (in my case another tool relays multi-KB collaboration prompts into opencode; the crash typically lands mid-stream, a few seconds after a stream starts).
- Wait for a crash: kernel log shows
opencode.exe: Worker: potentially unexpected fatal signal 7, TUI pane dies.
I can try to capture a core dump (ulimit -c unlimited) or run with BUN_CONFIG_DISABLE_TRANSPILER_CACHE=1 (currently testing this) if that helps pin it down.
Screenshot and/or share link
Not yet — the TUI just dies; kernel log above is the visible trace. Can add after next crash if needed.
Operating System
Windows 11 + WSL2, kernel 6.18.33.2-microsoft-standard-WSL2, Ubuntu, 13th Gen Intel i7-13620H
Terminal
tmux pane inside Windows Terminal
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.