Title: opencode 1.18.25 (linux x64, Bun standalone): SIGILL (ud2 assertion) during initial TUI render via OpenTUI — parent and child processes die identically
Environment
- opencode 1.18.25 installed via mise (
~/.local/share/mise/installs/opencode/1.18.25/opencode), Bun standalone executable
- Arch Linux, kernel 7.1.9, glibc 2.44, AMD Ryzen 9 9900X, Hyprland/Wayland, launched from a terminal (xdg-terminal-exec scope)
- Model provider session (GLM via zai-coding-plan) — likely irrelevant to the render path
What happened
Launched opencode --auto --prompt "<long multi-line text>" (content elided — plain prose with newlines, nothing exotic). Approximately 8 seconds after launch, during initial TUI rendering, both opencode processes (parent PID 1761403 + child PID 1761503) crashed in the same second with identical stacks. No session had been created yet. systemd-coredump retained both cores.
Signal: 4 (ILL) si_code: ILL_ILLOPN
Forensics
Faulting instruction is a deliberate ud2 trap (preceded by call + int3 padding), at binary offset opencode + 0x2407064 — i.e., an assertion/panic in the Bun/Zig layer, not an unsupported CPU instruction and not memory corruption.
Both processes' stacks are byte-identical. Key frames (systemd unwinder):
#0-#3 opencode + 0x2407064 / 0x2405266 / 0x32dd8bf / 0x44e35ad (trap + callers, Bun layer)
#4 libc.so.6 + 0x3e6f0
#5 /tmp/.<random-hash>-00000000.so + 0x1d061d
The /tmp/.<hash>-00000000.so module is OpenTUI core (extracted at startup, unstripped, full debug_info). Frame #5 symbolizes to:
buffer.OptimizedBuffer.trySetTransparentTextCellFast
opentui/packages/core/src/zig/buffer.zig:896 (discriminator 6)
So the crash thread was rendering text cells into the TUI buffer during startup when the Bun layer hit an internal assertion.
Recurrence
First occurrence after ~50 sessions across 5 days on 1.18.25 (installed 2026-09-01; zero prior opencode coredumps on this machine). Immediate relaunch with the same command succeeded and ran normally. One-off so far, but both processes dying simultaneously at the same assertion suggests a startup-render race rather than content-dependent input.
Questions / offers
- Is
+0x2407064 (1.18.25 linux x64 build) a known Bun-side assertion site reachable from the OpenTUI render path? If you can symbolize internally, the full coredumpctl stacks of both PIDs are available on request (they are 99 MB each — not attached).
- Any known startup-render race between parent and child both initializing the TUI buffer (transparent-cell fast path)?
- Happy to re-run with any diagnostic build or env var you suggest.
Title: opencode 1.18.25 (linux x64, Bun standalone): SIGILL (ud2 assertion) during initial TUI render via OpenTUI — parent and child processes die identically
Environment
~/.local/share/mise/installs/opencode/1.18.25/opencode), Bun standalone executableWhat happened
Launched
opencode --auto --prompt "<long multi-line text>"(content elided — plain prose with newlines, nothing exotic). Approximately 8 seconds after launch, during initial TUI rendering, both opencode processes (parent PID 1761403 + child PID 1761503) crashed in the same second with identical stacks. No session had been created yet. systemd-coredump retained both cores.Forensics
Faulting instruction is a deliberate
ud2trap (preceded bycall+int3padding), at binary offsetopencode + 0x2407064— i.e., an assertion/panic in the Bun/Zig layer, not an unsupported CPU instruction and not memory corruption.Both processes' stacks are byte-identical. Key frames (systemd unwinder):
The
/tmp/.<hash>-00000000.somodule is OpenTUI core (extracted at startup, unstripped, full debug_info). Frame #5 symbolizes to:So the crash thread was rendering text cells into the TUI buffer during startup when the Bun layer hit an internal assertion.
Recurrence
First occurrence after ~50 sessions across 5 days on 1.18.25 (installed 2026-09-01; zero prior opencode coredumps on this machine). Immediate relaunch with the same command succeeded and ran normally. One-off so far, but both processes dying simultaneously at the same assertion suggests a startup-render race rather than content-dependent input.
Questions / offers
+0x2407064(1.18.25 linux x64 build) a known Bun-side assertion site reachable from the OpenTUI render path? If you can symbolize internally, the fullcoredumpctlstacks of both PIDs are available on request (they are 99 MB each — not attached).