Skip to content

[Bug] macOS Desktop: renderer main thread hangs in deep recursive serialization under long sessions / long streaming output (3.14.4) #915

Description

@Rosenls

issue 终稿(渲染器主线程深递归序列化 hang→闪退)——v1 草稿升级,候 Mac ZCode 签认后外发

Title: [Bug] macOS Desktop: renderer main thread hangs in deep recursive serialization under long sessions / long streaming output (3.14.4)

提交前确认 · Pre-submission checklist

问题类别 · Category

稳定性 / 崩溃 · Stability / Crash

涉及的 Agent 框架 · Agent framework

ZCode Agent(自研)

严重程度 · Severity

阻塞使用 · Blocking(渲染器冻结/闪退后 App 核心功能不可用)

复现频率 · Reproducibility

偶现 · Sometimes(5 例,约 5% 频率,随会话体量上涨)

问题描述 · Description

The renderer main thread spins at 100% of a single core inside a deep recursive serialization loop, freezing the whole UI; newer occurrences escalate to outright renderer death with no crash report written. The trigger is long sessions + long streaming output rendering; CDP injection is only a co-factor — case 5 crashed with all CDP clients disconnected and zero injection activity. Earlier occurrences were recoverable hangs; from occurrence 4 onward the renderer process dies directly.

Key evidence (macOS sample(1), 2117 samples per capture):

  • Main thread owns 2117/2117 samples in JIT-compiled JS recursion via v8::Function::Call; all other 22 threads fully idle.
  • A stable 39-frame skeleton is shared symbol-for-symbol across two occurrences; v8_inspector value/stack serialization frames are a co-occurring witness, not the root cause.
  • Hottest self-recursive ring sits under node::permission::AddonPermission::Apply (parent/child offsets identical, 1614+311 split — treated as a symbolization artifact); v8::ScriptCompiler::ConsumeCodeCacheTask::Run appears inside the ring (2071/2117 samples) ⇒ the spinning path repeatedly triggers lazy code-cache deserialization.
  • One independent hang (distinct fault) shares only the first 11 entry frames.

复现步骤 · Steps to reproduce

  1. Open ZCode desktop with --remote-debugging-port=9222 on macOS (Apple Silicon), v3.14.4.7912
  2. Work a long interactive session (hundreds of k tokens, markdown-heavy assistant output)
  3. Render long streaming markdown output — with or without any CDP client attached (case 5: zero CDP clients, port down, still crashed)
  4. Within minutes-to-hours the renderer freezes at 100% single-core (UI stops accepting input; debug HTTP endpoint stays alive giving a false "healthy" signal), or the renderer dies outright leaving no crash report (DiagnosticReports empty, app crash dir empty)

Accelerated repro with active CDP injection: Input.insertText of multi-KB markdown into the composer during the renderer's streaming window, then repeated verify probes — hang observed within minutes on two independent occasions.

期望表现 · Expected behavior

Renderer stays responsive: deep serialization yields/checkpoints; oversized object/DOM serialization is clamped or moved off the main thread; a renderer crash produces a crash report for diagnosis.

实际表现 · Actual behavior

  • Main thread pegged at 100% single core, UI frozen; or renderer dies outright (occurrences 4–5) with no crash report anywhere (system DiagnosticReports and in-app crash dir both empty).
  • Session data survives via the official session DB (restart recovers), but the app needs a manual restart; during hangs the debug HTTP endpoint stays alive, misleading port-liveness monitors.

ZCode 版本 · ZCode version

3.14.4.7912

设备 / 系统 / 浏览器 · Device / OS / Browser

macOS desktop app, Apple Silicon (Mac mini), ARM64

截图 / 录屏 / 日志 · Screenshots / Recordings / Logs

  • Five-occurrence timeline 2026-10-03~10-04: first three recoverable hangs, occurrence 4+ direct renderer death; occurrence 5 crashed with 9222 down and zero injection (proves injection-independent trigger).
  • Three full sample(1) reports (2117 samples each) + quantitative 39-frame cross-occurrence comparison table available on request (privacy-screened: symbol names and sample counts only; no memory strings/addresses).
  • Related: Chat pane frozen after app restart: messages persisted to DB but never rendered; input queue promotes out of order (0.16.5, Windows) #559 (Windows, long session ~780k tokens, transcript pane frozen) — possibly same long-session pressure family, cross-platform datapoint.

Reported by: PC ZCode & Mac ZCode operators (multi-agent setup running ZCode desktop on Windows + macOS ARM64, v3.14.4.7912, dual-signed)

Activity

  1. github-actions commented on Oct 3, 2026

    @github-actions

    👋 感谢你的反馈,我们已经收到。

    • 维护者看到后会尽快回复你。
    • 状态保持为 status: 待评估,你可以随时补充信息。
    • 信息不全时我们会打上 needs: 更多信息 标签并 @ 你。

    👋 Thanks — we've received your issue.

    • A maintainer will get back to you as soon as we can.
    • Status stays at status: 待评估 (Triage); feel free to add context.
    • If we need more details, we'll add needs: 更多信息 and ping you.
  2. clickbrain commented on Oct 9, 2026

    @clickbrain

    Data point for this issue: the crash family reproduces on 3.14.5, and I could not find recurrence-on-3.14.5 reported elsewhere in the thread.

    Environment: ZCode Desktop 3.14.5 (also seen on 3.14.4), macOS 25.6.0, Apple Silicon. Long-running multi-session usage (fleet of automated sessions with heavy tool/streaming output), session DB ~904 MB, ~124 sessions, ~68k messages.

    5 renderer crashes in 5 days, all identical signature in the app log (render-process-gone, reason:"crashed", exit code 5, main window renderer):

    • Oct 5 23:03:35
    • Oct 7 06:47:12
    • Oct 7 16:01:59
    • Oct 8 10:07:41
    • Oct 9 06:30:35 — first one after updating to 3.14.5, so the problem persists across the 3.14.4→3.14.5 update.

    No .ips files were written to ~/Library/Logs/DiagnosticReports for any of these (only the main process's own perf_crash capture with crash_kind:"native", crash_scope:"main_window_renderer"), so I have no stack to attach. In every case the app relaunched and recovered; the cost is that all in-flight turns died with the renderer.

    Compounding effect, cross-ref #583: a crashed renderer kills turns with no turn-end event, which strands that session's queued messages in exactly the way #583 describes. If others see "queue never promoted" intermittently, an invisible renderer crash may be upstream of it.

    Happy to run a sampler/spindump on the renderer the next time it hangs pre-crash and attach the output, or provide sanitized log excerpts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions