🐛 SIGABRT crash in opencode serve (headless mode) during LLM streaming — no preceding error #33240

Problem

opencode serve (managed/headless server mode) crashes with SIGABRT (signal 6) during active LLM streaming sessions. The crash terminates the process abruptly, leaving connected clients frozen with no SSE events and no way to recover.

This happens consistently when running opencode serve standalone — even with zero other sessions or clients competing for resources.

Environment

• OS: Ubuntu 24.04 on WSL2 (Linux kernel 6.6.114.1-microsoft-standard-WSL2)
• Binary: Native Linux ELF (x86-64, glibc 2.39, AVX2 supported)
• OpenCode version: 1.17.9 (npm opencode-ai)
• Launch command: opencode serve --hostname 127.0.0.1 --port 4096
• Provider: opencode-omniroute with opencode-go/deepseek-v4-flash
• CPU: AMD EPYC, RAM: 48GB available

Crash Evidence

dmesg (kernel-level)

[ 1521.303099] opencode.exe: Worker: potentially unexpected fatal signal 6.
[ 1521.303941] WSL (32842 - CaptureCrash): Capturing crash for pid: 18458,
    executable: opencode.exe, signal: 6, port: 50005

systemd journal (lifecycle)

Jun 21 13:46:53 [lifecycle] periodic health check: OpenCode process exited, restarting...
Jun 21 13:58:16 [lifecycle] periodic health check: OpenCode process exited, restarting...
Jun 21 14:00:35 [lifecycle] periodic health check: OpenCode process exited, restarting...

OpenCode server logs

Last log entries before each crash show normal LLM streaming — no errors, warnings, or panics:

timestamp=2026-06-21T13:46:12.164Z level=INFO
    message=stream providerID=opencode-omniroute modelID=opencode-go/deepseek-v4-flash
    session.id=ses_119833fe7ffe1iRwcSjBtmFYem

The crash is sudden with no preceding error in the application log.

Reproduction Pattern

1. Start opencode serve --hostname 127.0.0.1 --port 4096
2. Connect a client (OpenChamber web UI or direct API calls)
3. Send messages that trigger multi-step agent loops (tool use, file reads, edits)
4. After 5-20 minutes of active streaming, the process dies with SIGABRT
5. The crash is NOT preceded by any logged error or OOM

What This Is NOT

• Not OOM: System has 48GB RAM, process uses ~450MB peak
• Not WSL interop: Binary is native Linux ELF, not running through interop layer
• Not resource contention: Reproducible with only one OpenCode instance running
• Not a network issue: The crash is a SIGABRT (self-termination), not a timeout or connection reset

Impact

When running behind OpenChamber (which manages opencode serve as a child process):

• The managed process dies silently
• Connected clients hang on in-flight HTTP requests (no response, no error)
• The UI freezes because SSE/WS event streams die with the process
• Client must restart the entire service to recover

Questions

1. Is there a known SIGABRT path in the codebase that fires during streaming?
2. Could an unrecovered goroutine panic be causing this? (Go default for unrecovered panics is SIGABRT)
3. Does the opencode-omniroute provider streaming path have a crash vector?
4. Is there a way to enable goroutine dumps on fatal signals for diagnostics?

Suggested Investigation

• Add runtime/debug.SetTraceback("crash") or a signal handler to dump goroutine stacks on SIGABRT
• Check for race conditions in session/stream management code
• Check if crash correlates with specific LLM response patterns (tool calls, long outputs, etc.)