Repository navigation
opencode 1.18.25 (linux x64, Bun standalone): SIGILL (ud2 assertion) during initial TUI render via OpenTUI — parent and child processes die identically #47037
Description
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 fullcoredumpctlstacks 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.
Activity
github-actions commentedon Sep 3, 2026
This issue might be a duplicate of existing issues. Please check:
opencode+0x2407064,libopentui.so+0x1d061d) and same symbolized frame (buffer.OptimizedBuffer.trySetTransparentTextCellFast,buffer.zig:896), also on Hyprland/Arch Linux. The trigger there is a compositor scale change causing a resize/redraw race; the startup-render race you describe may be the same underlying bug.opencode+0x2407064/libopentui.so+0x1d061d), sameILL_ILLOPNcrash, also during TUI startup — trigger is a partial terminal capability handshake, but the abort site is the same.SIGILL/ud2/ILL_ILLOPNon Arch Linux, one-off occurrence with no reproduction details.Given that #42094 and #41483 share the exact same binary offsets and symbolized OpenTUI frame, they are very likely the same root cause. You may want to add your core dump details as a comment there rather than tracking separately.
Dandroid-D commentedon Sep 6, 2026
Quick correction on the original report: I noted that full coredump stacks were available on request. To clarify, I can share fully symbolized stack text on request, but I will not share raw core files because they contain process memory and environment data.
Update on recurrence: this crash reproduced on 2026-09-06 at 16:27 (+07), confirming it is not a one-off.
Summary of the second crash:
c30f169b1bef81fa57467cd091ba53aab5235468), identical to the original reportopencode --auto --promptstartupud2) atopencode+0x2407064(exact same offset)buffer.OptimizedBuffer.trySetTransparentTextCellFastatopentui/packages/core/src/zig/buffer.zig:896(symbolized viaaddr2lineon the extracted/tmp/.<hash>-00000000.somodule)The failure signature is identical across independent runs on 1.18.25: a deterministic Zig panic trap (
ud2) hit in OpenTUI'sbuffer.zig:896during initial text rendering.chore: bump bundled Bun from 1.4.0 to 1.4.2
chore: bump bundled Bun from 1.4.0 to 1.4.2
thdxr commentedon Oct 11, 2026
Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (
opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊