anomalyco / anomalyco/opencode

[Desktop][Linux] NodeService utility process SIGABRTs during native teardown on every close

Open
#48,020 0 comments 0 reactions 1 assignee View on GitHub

@Brendonovich is already working on this.

Since Sep 8, 2026.

Dominant language
TypeScript
Stars
209k
Forks
27.5k
PR merge metrics
PR metrics pending

Description

Description

[Desktop] NodeService utility process terminates with SIGABRT during native teardown on every close (SteamOS)

Environment

  • Steam Deck (holo) / SteamOS 3.8.16
  • OpenCode Desktop 1.18.25 (Flatpak ai.opencode.opencode, Electron 42.3.3)
  • Kernel pipes all coredumps: core_pattern = |/usr/bin/python -m steamos_log_submitter.hooks.coredump %P %e %u %g %s %t %c %h %f %E, core_pipe_limit = 16

Problem

Closing OpenCode (last window/session) reliably terminates its Electron utility process (--type=utility --utility-sub-type=node.mojom.NodeService, which hosts the OpenCode sidecar server) with SIGABRT during native teardown — even though the sidecar reports a clean exit. OpenCode's own logs show sidecar exited { code: 0 } at close, while the kernel records a coredump for that same process in the same second. Users observe high CPU/fan ramp for minutes after closing the app, and a lingering ai.opencode.desktop --type=utility ... entry in ps.

Strongest evidence

A live capture tied the crash directly to the session under investigation:

  • Host PID 66690 was the OpenCode node.mojom.NodeService utility process for that session. Its /proc status showed NSpid: 66690 92, linking the host process to the in-sandbox process, with CoreDumping: 1 and Threads: 22.
  • coredumpctl and the systemd journal recorded PID 66690 terminating with SIGABRT at close time (14:47:12), matching the sidecar's clean-exit log line sidecar exited { code: 0 } at 14:47:12.650 to the second.
  • CoreDumping: 1 shows the apparent post-close "survivor" is not a live orphan: it is the crashed process's corpse, held unreaped while the coredump pipeline processes it (the kernel does not reap a crashed task until the core_pattern pipe consumer finishes; nothing is left listening on the sidecar's loopback port afterward).
  • Correlation across all retained records: 15/15 surviving shutdown records match a sidecar exited { code: 0 } log entry to the second with a subsequent NodeService SIGABRT coredump (36 OpenCode coredumps total in ~8 days on this machine; OpenCode's own crash.log never records any of them — the abort bypasses the app's crashpad reporting).
  • Separately, there are historical SIGILL shutdown events involving the main Electron process (thread 23), also at session close. These are the closes where the main process died first and no sidecar exited line was logged.
  • The exact native teardown component responsible for the abort has not been identified. The crash occurs after the sidecar's JavaScript has already run process.exit(0), i.e., inside Chromium/Node native teardown, so it is not visible to OpenCode's logging or crash reporting.

Relevant code path (from app.asar, out/main/index.js): window-all-closedapp.quit() (line ~4407); before-quit/will-quit fire void stopSidecars() (fire-and-forget, not awaited, ~4242–4248), which posts {type:"stop"} to the utility process; out/main/sidecar.js handles stop by stopping the listener and calling process.exit(0).

Secondary: SteamOS coredump pipeline amplifies the impact

This is a separate layer on top of the crash itself, not its cause:

  • SteamOS's core_pattern pipes the SIGABRT coredump into steamos_log_submitter.hooks.coredump, which references the OpenCode PID in its arguments (%P).
  • Observed during one close: the coredump submitter at ~88.6% CPU, still ~64.7% after several minutes; systemd-coredump at ~82% CPU in parallel; drkonqi-coredump-processor also participated.
  • The crashed process had roughly 430 MB RSS at the time. Note: Electron's ~1.5 TB VmPeak/virtual address space is not 1.5 TB of RAM or data — but large sparse address spaces make dump capture/processing slow.
  • The coredump was reported as truncated (COREDUMP_TRUNCATED=1).
  • Net effect: sustained CPU / fan / thermal load for minutes after closing OpenCode, plus a dead-but-visible process entry — presenting as a "process leak" or "app didn't close" symptom.

Reproduction

On this machine, every close does this:

  1. Launch OpenCode.
  2. Use it normally (prompt duration/workload does not appear to matter).
  3. Close the final OpenCode window/session.
  4. Observe the NodeService utility process terminate abnormally and a coredump appear (coredumpctl shows a fresh ai.opencode.desktop SIGABRT entry).
  5. Observe prolonged coredump processing / elevated CPU afterward.

No more precise reproduction condition has been established — the crash was not narrowed to a specific workload, and short sessions crash on close as well.

Expected behavior

Closing OpenCode should terminate its processes cleanly, without SIGABRT/SIGILL coredumps, and without triggering a large coredump-processing workload afterward.

Maintainer takeaway

Two things are worth investigating:

  1. Why does the Electron NodeService abort during native teardown after the sidecar has already exited cleanly (exit 0 → SIGABRT microseconds later)? This is the primary issue: a deterministic shutdown-path crash in the Electron utility/browser teardown on this environment, invisible to OpenCode's own crash reporting. A coredump stack from an affected close (e.g., via coredumpctl info <pid>) should identify the aborting component.
  2. Whether the SteamOS coredump interaction (minutes of ~1-core CPU per close) is expected or can be reduced independently — secondary, and a SteamOS-side question, but it is what turns an invisible shutdown crash into a noticeable thermal/CPU event for users.
Plugins

None. I have a small local modification to OpenCode that triggers the sound notification when user interaction/dialogue is required.

OpenCode version

1.18.8

Steps to reproduce
  1. Launch OpenCode.
  2. Use it normally (prompt duration/workload does not appear to matter).
  3. Close the final OpenCode window/session.
  4. Observe the NodeService utility process terminate abnormally and a coredump appear (coredumpctl shows a fresh ai.opencode.desktop SIGABRT entry).
  5. Observe prolonged coredump processing / elevated CPU afterward.
Screenshot and/or share link

No response

Operating System

SteamOS 3.8.16 (Steam Deck)

Terminal

N/A — OpenCode Desktop (Flatpak)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.