[bug] v0.8.0 升级后一发消息宿主即崩：v0 abort-cause 清扫未完成（EXC_BREAKPOINT on libuv-worker）

[WuFenG-Hub]

IDBots v0.8.0：升级后「一发消息宿主即崩」（EXC_BREAKPOINT / libuv-worker）

可直接作为 issue 正文提交。证据等级已逐条标注：[已证实] / [强关联·未证实] / [未核实]。

环境

项	值
IDBots	0.8.0（build 0.8.0），commit f83b886e = 官方 tag v0.8.0
上游	metaid-developers/IDBots
系统	macOS 26.6.2 (25G83)，arm64
内嵌运行时	@deepseek-ai/dsh 0.1.5-rc.2（Contents/Resources/dsh-runtime）
发生时间	2026-09-12
升级路径	v0.7.0 → v0.8.0

症状

启动正常，界面正常。在既有会话里发一条消息 → 宿主主进程立刻崩溃退出（macOS 弹出「IDBots 意外退出」）。新建会话未观察到崩溃。

崩溃签名（4 次复现，完全一致）[已证实]

• bug_type=309，exception.type=EXC_BREAKPOINT，signal=SIGTRAP，termination.indicator="Trace/BPT trap: 5"
• 故障线程名 libuv-worker（线程池工作线程）；主线程当时正常停在 AppKit 事件循环
• 故障帧 frame[0].imageOffset = 0x5500dc8（Electron Framework）—— 4 次崩溃完全相同，即确定性崩溃点
• 故障指令 atPC 首条为 0xD4200000（brk #0）→ 原生层主动陷阱，不是内存错误、不是 JS 异常
• 崩溃进程中未加载任何第三方 .node 原生插件（koffi/sharp/node-pty 均属 dsh-runtime 子进程）
• 诊断字段 asi / abort_cause / is_js_error 全部缺失；ELECTRON_ENABLE_LOGGING=1 捕获的 stderr、系统统一日志、应用 main.log 三处均零输出

复现条件

1. 机器上存在 0.8.0 之前版本的会话数据
2. 其中至少一个会话在旧内核上被 steer 或 cancel 过（该轮 turn/end 的 abort cause 会被写成裸字符串）
3. 打开该会话并发一条消息

→ 命中率很窄，因此社区几乎无人碰到、也就无人上报。

证据链

1. 崩溃报告：4 份 .ips 同签名、同一故障偏移 [已证实]

2. logs/cowork.log 停在固定位置：Resolved API config → memory:promptBlocks → DSH reasoning effort 之后再无输出；应用 main.log 同样在 [GigSquare Rating] updated 0 services 后戛然而止 [已证实]

3. 预热失败垫刀：每次启动 prewarmDshRuntime 都失败——

   [WARN] [prewarmDshRuntime] Warmup failed; first turn will cold-start
   error: Provider 'deepseek' does not offer enabled model 'deepseek-v4-flash-vision-exp';
          provider selection is required.
   

   于是走冷启动，把清扫推迟到首轮发言才执行，这正是"一发言就崩"的由来 [已证实]

4. 清扫「做了一半」的量化铁证 [已证实]：

   backups/v0-abort-cause/ 下每个会话产物备份的创建时刻呈两段式分布：

   备份时刻	份数	归属
   14:56	36	宿主那趟（崩死前做到的）
   15:14 / 15:15	42 + 56 = 98	事后用系统 Node 补跑完成的剩余部分
   合计	134	36 + 98

   而补跑那趟的返回值是 {"scanned":806,"patched":98,...} —— 补跑的 98 与备份新增的 98 完全吻合。
   即：宿主那趟只在 36 个会话上写出了备份就死了，剩下 98 个从未被处理。

5. marker 缺失 [已证实]：

   • marker dsh-sessions/v0/.v0-abort-cause-sanitized 在补跑前全盘搜索不存在（ls 明确返回 No such file or directory）
   • 按 sanitize-v0-abort-cause.mjs 自身逻辑：marker 不在 = 这一趟从未完成，宿主下次启动会全量重跑

6. 时间吻合 [已证实]：最早的备份目录时间戳为 09-12 14:56，首次崩溃为 14:56:12 —— 同一分钟

根因判断

已证实部分：v0.8.0 引入的一次性清理 sanitize-v0-abort-cause.mjs（位于 dshKernel.ensureRuntime，在明文→zstd 编码迁移之后执行）从未跑完，marker 未落地，宿主每次冷启动都重跑，并在首轮发言时崩溃。

强关联、尚未证实部分：崩溃发生在该清扫内部。

⚠️ 反证：把同一份 sanitize-v0-abort-cause.mjs 用系统 Node v24.12.0 单独执行，跑得干干净净、零崩溃：
{"scanned":806,"patched":98,"patchedEvents":253,"skipped":false}
因此"崩在清扫里"目前只有时间与调用链的关联，没有函数级证据——详见下方"未核实"。

已实测有效的绕过方式

App 未运行时，用系统 Node 单独执行该清扫使其落 marker：

// node --input-type=module
const m = await import('<IDBots.app>/Contents/Resources/dsh-runtime/lib/sanitize-v0-abort-cause.mjs')
await m.sanitizeV0AbortCauses('<userData>/dsh-sessions/v0', { log: console.log })

结果：marker 写入 {"version":1,"scanned":806,"patched":98,"patchedEvents":253,...}；二次运行返回 {"skipped":true}。
宿主重启后发消息不再崩溃，验收证据：DiagnosticReports 无新崩溃文件、main.log/cowork.log 继续正常推进。

给上游的修复建议

1. 清扫必须可断点续跑。当前 marker 只在整趟扫完后一次性写入，任何中途失败（含进程死亡）都会导致每次启动重跑全量 806 个会话。建议改为 per-session 标记，或把已处理会话记入一个可增量提交的清单。
2. 清扫不应在 ensureRuntime 的关键路径上阻塞。它属于一次性数据迁移，应异步化，且失败不应影响运行时启动。
3. 补诊断打点：清扫入口/出口、每个会话处理前后、marker 写入前后各打一条日志。本次排查的最大障碍恰恰是"崩溃零输出"，若有这些打点，定位时间可从数小时降到数分钟。
4. prewarmDshRuntime 遇到已退休模型应自动折叠为当前模型（src/renderer/config.ts 里已有 'deepseek-v4-flash-vision-exp' → DEEPSEEK_DEFAULT_MODELS[0] 的别名映射），而不是 WARN 后放弃预热——预热失败把清扫挤到"首轮发言"，直接改变了故障的表现形态。
5. 崩溃可观测性：考虑启用 Crashpad 或给主进程装 uncaughtException/崩溃回调落盘，当前 4 份 .ips 全部无 asi、无 abort 原因，排障成本极高。

未核实 / 不确定性（不掩盖）

• [未核实] 崩溃具体断在哪一行原生代码。Electron Framework 无符号表，.ips 中所有帧的符号解析均不可信（ares_dns_rr_get_ttl+巨大偏移），asi 字段缺失。
• [未核实] 清扫在纯 Node 下可跑通、在 Electron 内会崩——若二者确有差异，方向应转向「宿主 Node 与系统 Node 在该 zstd/线程池路径上的行为差异」，而非清扫逻辑本身。
• [未核实] 是否还有第二处引用旧模型 id。本次仅修掉配置目录中的死条目，路由逻辑本身未动。
• 本次修复动作只做了两步：①用系统 Node 跑完清扫落 marker；②把 app_config.providers.commandcode.models[] 里已退休的 deepseek/deepseek-v4-flash-vision-exp 改名为 deepseek/deepseek-v4.1-flash。未修改任何源码，未向仓库提交任何内容。

[WuFenG-Hub]

v0.9.3 状态复核（2026-09-16，报告机实测）

一、报告机现状 [已证实]

• 自 2026-09-12 15:33 之后无新的崩溃报告：DiagnosticReports 里 IDBots 最后一份 .ips 是 IDBots-2026-09-12-153349.ips，此后跨过 0.9.0 / 0.9.1 / 0.9.2 / 0.9.3 无新增。
• marker 已落地：dsh-sessions/v0/.v0-abort-cause-sanitized = {"version":1,"scanned":806,"patched":98,"patchedEvents":253,...}，0.9.3 下清扫被 marker 短路（skipped:true）。

二、证据链第 3 条（预热恒失败 → 清扫被推迟到首轮发言）在 0.9.3 已消除 [已证实]

PR #36（已合入 v0.9.3）修的正是这条链：runDshRuntimeWarmup() 预热的是 listSessions()[0]，而该行恒为 pinned 会话；其存储的 model/provider 一旦失效，resolveSessionDshRoute() 抛 ModelProviderSelectionError，且该异常在 route = sessionRoute ?? defaultRoute 之前逃逸，于是整个预热降级为 WARN、每次启动都冷启动。修复把该解析隔离进独立 try/catch，死路由降级到默认路由并留日志。

本机日志佐证：最后一次 [WARN] [prewarmDshRuntime] Warmup failed; first turn will cold-start 是 2026-09-13T02:44:45Z（#36 合入前）；自 2026-09-13T04:37:41Z 起每次启动均为 [INFO] [prewarmDshRuntime] DSH runtime ready（含 09-15T01:33Z、09-15T11:02Z、09-16T01:27Z）。

三、设计层面的脆弱性在 0.9.3 未变 [已证实]

1. 仍在关键路径上被 await：src/main/libs/dshKernel/dshKernel.ts 的 ensureRuntime() 中，await sanitizeV0AbortCauses(config.sessionRoot, …) 位于 zstd 迁移之后、创建 runtime client 之前。同一个函数里 zstd 迁移的注释明写 "atomic per artifact, crash-recoverable"，而清扫自称 "one-time marker-gated sweep"，两者恢复语义不一致。
2. marker 仍是 root-level、全或无：随 0.9.3 安装包发布的 dsh-runtime/lib/sanitize-v0-abort-cause.mjs 实测仍是「整趟扫完才在末尾写 marker」（命中 marker 即 skipped:true；末尾才写入）。任何一次中途失败（含进程死亡）仍会让下次冷启动全量重扫整个 root。
3. 需要说准确的一点：单个产物的写入本身是原子的（rename），所以中途死亡不会损坏数据、重扫也是幂等的——风险在「反复全量重扫」这个动作本身，以及它发生在冷启动的关键路径上。这与原报告建议 1 一致。
4. 建议 1（per-session 可续跑标记）与建议 3（清扫入口/出口打点）在 0.9.3 未见实现；建议 4（预热遇已退休模型自动折叠）由 fix(cowork): keep DSH startup warmup alive when the pinned session model is stale #36 实质解决；建议 5（崩溃可观测性）未见变化。

四、不确定性（不掩盖）

• [未核实] 「崩在清扫内部」在 0.8.0 上仍只有时间与调用链关联。本机在 0.9.3 上已无法复现（marker 已落），因此我拿不出「0.9.3 修掉了该崩溃」的正面证据。能说的只是：本机在 0.9.3 上不再复现，且触发它的那段路径（预热恒失败）已被 fix(cowork): keep DSH startup warmup alive when the pinned session model is stale #36 消除；清扫自身的恢复语义未改。
• [未核实] 是否有其他机器在新装/升级时命中同一形状。要验证需要一个「清扫被中途打断」的现场，例如升级后立刻强杀进程，再看下次冷启动是否重扫全量。

建议

本 issue 可收窄为两项并保持打开：①清扫的可续跑性（root marker → per-session 标记或可增量提交的清单）；②把清扫移出 ensureRuntime 的阻塞路径。若维护者认可这个方向，我可以提一个带「中途失败」用例的 PR。