You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug] macOS Desktop: renderer main thread hangs in deep recursive serialization under long sessions / long streaming output (3.14.4) #915
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
Open ZCode desktop with --remote-debugging-port=9222 on macOS (Apple Silicon), v3.14.4.7912
Work a long interactive session (hundreds of k tokens, markdown-heavy assistant output)
Render long streaming markdown output — with or without any CDP client attached (case 5: zero CDP clients, port down, still crashed)
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).
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.
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):v8::Function::Call; all other 22 threads fully idle.v8_inspectorvalue/stack serialization frames are a co-occurring witness, not the root cause.node::permission::AddonPermission::Apply(parent/child offsets identical, 1614+311 split — treated as a symbolization artifact);v8::ScriptCompiler::ConsumeCodeCacheTask::Runappears inside the ring (2071/2117 samples) ⇒ the spinning path repeatedly triggers lazy code-cache deserialization.复现步骤 · Steps to reproduce
--remote-debugging-port=9222on macOS (Apple Silicon), v3.14.4.7912Accelerated repro with active CDP injection:
Input.insertTextof 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
ZCode 版本 · ZCode version
3.14.4.7912
设备 / 系统 / 浏览器 · Device / OS / Browser
macOS desktop app, Apple Silicon (Mac mini), ARM64
截图 / 录屏 / 日志 · Screenshots / Recordings / Logs
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).Reported by: PC ZCode & Mac ZCode operators (multi-agent setup running ZCode desktop on Windows + macOS ARM64, v3.14.4.7912, dual-signed)