Repository navigation
server: v2.0.11 background service segfaults repeatedly (SIGSEGV, Linux x64) #50246
Description
Description
The background service process (opencode serve --service) crashed with SIGSEGV 9 times in one day (2026-09-20, 13:15–23:32 local time). Each crash dumps a large core (240–380 MB). The client auto-relaunches the service within ~1 minute, so the user-visible symptom is OpenCode suddenly "restarting by itself" (all TUIs disconnect and reconnect; sessions persist).
Nothing is logged before the crashes (opencode.log shows normal activity — git snapshots on two worktrees). coredumpctl reports Signal: 11 (SEGV); the captured stack is the runtime abort path (pthread_kill → raise → native frames in the stripped Bun build).
Plugins
opencode-anti-loop, sglang-guard, plur-memory (local plugins).
OpenCode version
2.0.11 (latest v2 tag). Crashes started on 2026-09-20; previous days were clean. No build or config change known to correlate with the first crash.
Steps to reproduce
Not reproducible on demand. Spontaneous crashes on 2026-09-20 (core-dump report times): 13:15:49 · 14:20:58 · 14:56:27 · 15:12:51 · 15:15:40 · 16:43:10 · 17:12:40 · 18:39:41 · 23:32:28.
Setup context: long-running Linux desktop (3 d uptime), several TUIs sharing one managed service, heavy git-snapshot activity in two large worktrees on external drives.
Screenshot and/or share link
coredumpctl info excerpt (latest crash):
Signal: 11 (SEGV)
Command Line: /home/<user>/.opencode/bin/opencode serve --service
#0 __pthread_kill_implementation (libc.so.6)
#1 __GI_raise (libc.so.6)
#2–#5 native frames in the opencode binary (stripped)
Module /tmp/.bun-1000-*.so without build-id
Core files are retained locally — happy to provide more detail if useful.
Operating System
Ubuntu 24.04.1, kernel 7.0.0-31-generic, x86_64
Terminal
GNOME Terminal (VTE); TERM=xterm-256color, COLORTERM=truecolor; shell /bin/bash
Activity
tonykee commentedon Sep 30, 2026
Also seeing this on 2.0.12 — same environment class (Linux x64, Ubuntu, kernel 7.0.x) and the same
/tmp/.bun-*.somodule in the crash. (I have since upgraded to 2.0.20; see the end of this comment.)Version / environment
opencode --version: 2.0.12 while the crashes below were recorded (binary at/opt/opencode/bin/opencode, symlinked from/usr/local/bin/opencode); upgraded to 2.0.20 on 2026-09-307.0.0-28-generic, x86_64opencode serve --service); usually a single TUI attachedSymptom
Identical:
opencode serve --servicesegfaults, the client relaunches it within ~1 minute, TUIs disconnect andreconnect, sessions persist.
Frequency
Ubuntu's apport crash handler recorded 31
opencodecrashes between 2026-09-19 and 2026-09-30 (10 of them on2026-09-30 alone). Nearly all are
serve --service; a couple are the plainopencodeTUI process.Crash times on 2026-09-30 (local time): 00:54:20, 03:09:01, 10:01:28, 11:03:49, 11:08:52, 11:21:26, 12:14:20,
12:54:52, 15:19:46.
Corroborating the auto-relaunch: each new
run=inopencode.logstarts a few seconds after an apport SIGSEGV entry,e.g. crash 11:03:49 → new run at 11:03:55; crash 12:14:20 → new run at 12:14:26.
Crash report
/var/crash/_opt_opencode_bin_opencode.1000.crash(apport):This is not an OOM — RSS was ~215 MB at the crash (VmPeak is just the ~11 GB virtual space).
ProcMapsshows the same/tmp/.bun-*module you noted (no build-id):The 12.8 MB
.socontains Rust code (fff-style fuzzy file search + git-status strings, e.g.Arc counter overflow,untracked,staged_modified).Logs
Nothing is logged before the crashes (matches your report). The only recurring line is:
every ~5 minutes.
models.devresponds HTTP 200 from this host, so this looks like unrelated network noise, not thecause. There are no watcher/inotify errors (
ENOSPC/EMFILE) in the log.Note on core capture
apport refuses to write new reports ("report already exists and unseen, skipping to avoid disk usage DoS"), so
/var/crashkeeps only one stale report, and the stored core is truncated (called for global pid ..., signal 11, core limit 0) — decompressing it fails, so no local backtrace is available.Other
In the same window apport also recorded a single SIGSEGV of an unrelated local binary (
strataengine) and one ofpython3.14— almost certainly unrelated, but mentioning it for completeness.Upgraded to 2.0.20 on 2026-09-30 (the
/optbinary was replaced;opencode service statusnow reports 2.0.20). Nocrash has been recorded since the upgrade. I will follow up here if it recurs, and will try
opencode --standaloneifit does.
piknockyou commentedon Sep 30, 2026
Same visible pattern here: the service kept restarting by itself, with TUIs disconnecting and reconnecting. Mine was a hang rather than a crash, so your SIGSEGV is probably a different bug - but one thing may still be worth ruling out, since your logs show git-snapshot activity on large worktrees.
Check what opencode considers the project root when it runs:
git rev-parse --show-toplevel.gitis the culprit - the snapshot scan then walks that whole tree twice per turn. Deleting that leftover.gitand starting opencode inside a real project removes the condition. (An accidental repo is usually empty - zero commits - so nothing is lost; rename it instead if unsure.)git ls-files --others --exclude-standard | wc -l- if that is in the 100k+ range, the heavy directories (node_modules, target, build, caches) need to go into.gitignore, or snapshotting disabled with"snapshot": false.For me, deleting the stray
~/.gitremoved the failure completely. If neither applies here, treat this as noise - and your core dumps are the more useful lead.gandb commentedon Oct 2, 2026
Update from the original reporter — still crashing on 2.0.22.
Upgraded 2.0.21 → 2.0.22 today (~09:29 local); the bug persists. Crashes today alone: 11:17:54 and 11:39:53 — the second one was the service spawned at 11:18:50, i.e. a process actually running 2.0.22. Nothing is logged before the crashes (matches the original report); client auto-relaunches within ~1 minute.
Cores (systemd-coredump, all SIGSEGV,
opencode serve --service; 11 total since 2026-09-30):In-binary stack offsets — identical across every core inspected:
Frames #2–#5 are byte-identical in all cores examined → a single recurring crash path, not random corruption at different sites.
Impact (may help triage): every crash kills all in-flight tool calls in all sessions (
Tool execution interrupted: <tool>), includingquestiontool calls awaiting a user answer — a pending question left unanswered dies at the next crash, which looks like a "timeout" from the user's side but is this crash.Ruled out here: not OOM (~10 GiB free, no kernel OOM logs); not the stray-
.git/giant-tree snapshot issue suggested earlier (no stray.git; every project root resolves normally on this machine).Cores are retained locally — happy to provide anything else.
Dante-dan commentedon Oct 2, 2026
The repeated offsets are useful, but the frames shown stop in the runtime signal/abort path; the mapped FFF and watcher modules alone do not identify the faulting component. I also checked the current service-side native wrappers and cannot yet connect this to a specific lifetime bug.
Could you share the installation source and commit/build identity of the exact 2.0.22 executable that produced a retained core, plus the complete thread backtraces (
thread apply all bt) and loaded-module/build-ID information from that core? Service stderr around the crash, especially a Bun crash report URL if one was emitted, would also help map the offsets.This should stay separate from the stray-repository hang, which your latest report already rules out.
gandb commentedon Oct 2, 2026
Thanks — here are the install/build identity, the core data, and the stderr status.
Install source and build identity (2.0.22 executable that produced a retained core)
~/.opencode/bin/opencode(installer footprint:~/.opencode/{bin,node_modules,package.json}; self-managed updater).updated OpenCode from=2.0.21 to=2.0.22 method=curl), and the background service restarted onversion-mismatchimmediately after. The crashing process (PID 2358727, spawned 11:18:50 local) was started from that file, and the file is unchanged since (still 2.0.22; no later update event in the log).sha256 = 32cf5aa0a69a650e36277e3315d189835ddc79fb9aa1d0aef5025be5af5ad122BuildID[sha1] = 5afca2666bfab8605a934f1b6231dacae0518a5f,not stripped— but the.symtabonly carries exported shim symbols (napi_*,uv_*,v8::*wrappers); none of the crash offsets have symbol coverage, gdb shows??for all of them and there is no DWARF.Core and thread backtraces
Core retained by systemd-coredump:
core.opencode.1000.d70bc1b2091e4e1e80372f359673b03b.2358727.1790937577000000.zst(243 MB on disk) — SIGSEGV, 2026-10-02 11:39:37 WEST,/home/<user>/.opencode/bin/opencode serve --service, 35 threads.Crashing thread as gdb unwinds it (unwind stops at #4 — no usable unwind info past that point):
The systemd-coredump journal trace for the same core continues past that point (identical offsets to the earlier reports):
siginfofrom the core: thesi_pid/si_uidfields read back as pid 2358727 (the process itself) / uid 1000 — consistent with the process raising SIGSEGV on itself viaraise()in the runtime's crash path. (Also consistent: the kernel logged nosegfault at ...entry for any of these crashes.)All other threads were idle at crash time: runtime threads parked in
syscall/futex, 6libonnxruntime.so.1condition-wait threads (from theplur-memoryplugin) and 2 watcher threads (the bundled@parcel/watchernative), one thread parked in-binary atopencode+0x18f6d86. Completethread apply all bt(all 35 threads): in the collapsible block belowLoaded modules (from the core)
Note:
/tmp/.bun-1000-89812e6e6a68aaeb.sohas no build-id (systemd flagged it too); the other two.bunmodules are extracted at runtime and content-hash-named (no separate build metadata of their own). Happy to pull any per-module detail you want.Service stderr / Bun crash report
/dev/nulland stderr is a socket to that client (verified on the current instance, same spawner). So crash-time stderr is not persisted anywhere on disk, and the service log has nothing at the crash.bun.report) in the service log and the state directory: none found. If the runtime emitted one, it went over that socket.Cores for both 2.0.22 crashes (11:17:54 and 11:39:53) are retained — happy to run any specific gdb commands you want on them.
Complete thread apply all bt (all 35 threads)
Dante-dan commentedon Oct 2, 2026
Thanks, this identifies the executable and fills in the thread/module evidence. The core is stopped in the runtime's re-raised SIGSEGV, so the self-reported PID and idle worker threads do not establish where the original fault occurred. The journal's
+0x358db92and gdb's0x378db92differ by the ELF load address0x200000; that is not a different crash site.Yes, please capture the service's stderr for the next crash, including any Bun crash report URL and the runtime version/revision printed with it. Please keep that capture paired with the exact executable hash and core timestamp. The native libraries loaded by
plur-memoryare an additional variable, but their presence is not evidence of blame; a separate run with that plugin disabled would be useful as a comparison if the crash is reproducible.There is no need to resend the existing backtraces or build identity.
opencodejr commentedon Oct 28, 2026
Thanks for the detailed core analysis and the follow-ups. Two things have changed since your last update that may matter here:
servesegfault on Bun 1.4.2 (serve: Bun 1.4.2 segfault (address 0x3D8) after long uptime on Windows #53688) was closed as fixed by that upgrade..soloaded in your crashing process) now starts on the first search instead of at service startup (fix(core): start fff search lazily on first find #58959).Could you please:
opencode upgrade, or let the updater run), confirm withopencode --version, and tell us whether the service still segfaults.panic(...)block and thehttps://bun.report/...URL from that log, along with the core's timestamp.plur-memory, since it loads its own native libraries) and tell us whether the crashes stop.You can reply here with the details, or edit the issue. If you edit it, please also leave a short comment saying you've updated it, so we know you're done.
Related issues, ordered by how closely they match (none looks like an exact duplicate):
servesegfault on bundled Bun 1.4.2 after long uptime (Windows), closed as fixed by the Bun upgrade@parcel/watcheraddon (Windows)opencodejr commentedon Oct 31, 2026
Closing this for now, since we haven't heard back since we asked about the latest release. Thanks for all the core-dump analysis you've already posted.
The backtraces stop where Bun re-raises the signal, so they don't show where the crash actually happened. To go further we'd need to know whether the
opencode serve --servicesegfaults still happen on v2.1.3 or later (which bundles Bun 1.4.4 instead of 1.4.2). If they do, we'd also need thepanic(...)block andhttps://bun.report/...URL from the service's stderr, for example by runningopencode serve --service 2> ~/opencode-service-stderr.logyourself.If it still crashes on a current version, please comment here with those details and we'll reopen it. For related crash reports, see #53688 (a similar long-uptime
servesegfault on Bun 1.4.2) and #53214.