[已定位] 宿主长时间无响应：第三方工具结果压缩插件的 cd 正则指数回溯（非 OOM / 非 abort / 非超长单行）

[cinast]

原始报告（2026-11-15 上午）— 保留，结论已被下方更新推翻

现象：

1. 在 shell 工具执行期间，宿主长时间无响应；等不及后用户手动结束进程（taskkill），代理侧因此看到 kill-0 probe failed (ESRCH)。
2. 事后检查：Get-WinEvent Application 无条目、WER\ReportArchive|Queue 无 11-15 目录、无 stderr（当时启动命令未重定向）。
3. 当时的两条假说：①单条多 MB 单行的 stdout 在宿主侧被逐行处理/截断时的同步开销；②内存耗尽后的 fatal abort。

证据缺口（当时）：拿不到"卡住时"的栈——宿主没带 --inspect，只能等它退出看退出码。

更新（同日 13:30）：已定位，假说全部推翻

假说①②都不成立：不是 OOM、不是 abort、也不是超长单行。

决定性证据

给宿主加 --inspect=127.0.0.1:9229，用一个脱离宿主进程树的看门狗每 10 s 探测 http://127.0.0.1:3080/dgh-dashboard/，连续 2 次超时即用 CDP Debugger.pause 抓栈。三次连续抓取，6 帧完全一致：

commandContext            lib/reducers/command.js:74
commandTokens             lib/reducers/command.js:98
reduceGit                 lib/reducers/git.js:24
applySemanticReducers     lib/reducers/index.js:48
ctx.on.prepend            lib/index.js:284
processTicksAndRejections node:internal/process/task_queues:103

全部来自第三方插件 dsh-tool-result-trimmer@2.8.0——它挂在 tools/post-execute 上，每个工具结果都同步跑一遍。

关键读数：

• Debugger.pause 延迟 101 ms：主线程在跑 JS，不是阻塞在系统调用，也不是卡在分配；
• 进程 alive=1、RSS 平稳在 577–795 MB：没有任何"死前峰值"；
• 触发命令输出只有几 KB：cd ~/…/src/mailbox 2>/dev/null && sed -n '50,75p' tools.ts && grep -rn "args?.from" . | head -5。

⇒ "超长单行 / 单次大分配"这条线可以整条划掉。进程既没崩也没 OOM，是主线程被一条正则锁死：UI 全黑、HTTP 探针全超时、工具结果没能落盘。没有 stderr 不是因为 stderr 没接上，而是根本没有终止事件可写（最后是用户 taskkill）。

根因

该插件 commandContext() 里一条嵌套量词正则：

/^cd\s+((?:[^\s'";&|<>`$()#]+|'[^'\n\r]*'|"[^"\n\r]*")+)\s*&&\s*(.+)$/

cd <较长目标> 2>/dev/null && … 这种形状（目标后面不是 &&）会让它失败后指数回溯。离线复跑同一函数：目标 16 字符 168 ms、20 字符 340 ms、24 字符 3 548 ms、39 字符 >10 s（被 timeout 杀掉），每 +4 字符约 ×8–10。

上游已报：Jaylor-Wang/dsh-tool-result-trimmer#1（崩因）、#2（审计：20+ 次卡死、语义 reducer 实测命中 0 次、宣传范围大于实现）。

对既有加固建议的影响

1. stderr 重定向：仍值得保留（成本≈0），但对这类事故无效——没有"崩溃前落盘"的时刻，进程一直活着。
2. 按字节流式截断：作为独立加固正确，对另一类现场（上游请求被取代/流被中断）有用；不是本次原因。
3. 超长行保护：可纳入常规加固，但修不了本次问题。

真正该加进宿主的一条

每个工具结果的同步处理要有时间预算，超时即熔断（跳过处理、保留原文、记 reducer-slow）。

插件生态里的 "fail-open" 几乎都只包 try/catch，而正则卡死不抛异常，只是永不返回。最小可行版：tools/post-execute 的每个 handler 用 AbortSignal + N ms 预算包裹，超时即放弃该 handler 的输出并原样透传——任何一个第三方 reducer 写坏都不会再拖垮整个宿主。

可复用的取证方法

--inspect=127.0.0.1:9229 启动宿主 → 外部看门狗探测 UI 端点（2 次超时判定）→ Debugger.pause 取 callFrames + Runtime.getHeapUsage → 落 JSON。5 分钟能定位到函数级，且不需要事先知道原因。

[cinast]

更正（发帖人自纠）：上面两次「宿主静默消失」的 ESRCH，不是自崩，是用户手动 taskkill 掉的——宿主在 shell 工具执行期间会长时间无响应（用户原话：「卡很久都不可能响应」），等不及主动结束进程。

所以本贴的真实标题应是：shell 工具输出超长单行时，宿主进入长时间无响应，而不是进程自崩。

• 「无 stderr / 无 WER / 无 dump」因此是预期结果（被外部 TerminateProcess 结束），不构成「静默崩溃」的证据；
• 要查的是为什么宿主会卡到无法响应：候选是单条多 MB 单行的 stdout 在宿主侧被逐行处理/截断时的同步开销（约 1 MB/line，见原贴两例），但尚未验证；
• 取证方式改为「卡住时抓进程 dump/栈」，而不是「等进程退出看退出码」。

[2SinceJuly]

三个问题都能从「为什么是静默」这个角度回答，而且你的两个假说可以合并成一个：不是 OOM，是无 dump 的 abort。

为什么没有任何痕迹

V8 的 fatal abort 走 abort()，不产生 WER 条目 —— 这解释了 Get-WinEvent Application 和 WER\ReportArchive|Queue 同时为空。Windows 只在进程触发未处理异常（SEH）时记录 WER；V8 的 FatalProcessOutOfMemory / CHECK 失败是直接 abort，跳过整条上报链。

这意味着一件事：你缺的不是"崩溃前落盘"，而是 stderr 从来就没接到文件上。你自己已经指出来了（cmd /c 没重定向），这是最关键的一条，其他的都是推论。

你的三个问题

1. 宿主有没有崩溃前落盘机制？

没有面向用户的。但有两个成本极低的替代，第 1 条现在就能做：

dsh web > "%LOCALAPPDATA%\dsh\host-out.log" 2> "%LOCALAPPDATA%\dsh\host-err.log"

V8 在 abort 前会把 # Fatal error in ... 和完整的 JS 栈写进 stderr —— 这就是缺的那块证据，不需要 DSH 改任何代码。

第二条（值得作为建议提）：进程退出时由拉起着写一行 marker，即你提议的 <pid> exit=<code>。但注意 exit=0xC0000409（STATUS_STACK_BUFFER_OVERRUN，abort() 在 Windows 上的表现）和真正的访问违例 0xC0000005 是两种完全不同的成因 —— 前者是 V8 主动 abort，后者才是内存损坏。区分靠退出码即可，这正是 WER 给不了的信息。

2. shell 输出能否按字节硬截断？

能，而且这是标准做法。现在的 maxBytes + spill 如果是"先按行拆分再判大小"，那超长单行会在拆分阶段就被整体读进内存 —— 也就是你怀疑的那次大分配。

按字节截断的正确形状是在流式读取时累积字节数，超过阈值直接落 spill 并标记：

[line truncated at 1048576 bytes, N more bytes in spill]

关键是标记必须显式出现，否则调用方拿到的是"看起来完整但其实是片段"的输出，比截断本身更危险。

3. 加"超长行保护"值不值？

值得，但阈值不要照抄 1 MB。你两次现场的共同点是 minified 单行 —— 这类文件单行常在 200 KB 到数 MB。建议两个参数：

• 软阈值（如 256 KB）：超过时该行不进内存逐行解析，直接流式落 spill
• 硬上限（如 1 MB）：超过时截断并打标记

这样普通日志（无论多少行）完全不受影响，只有病态单行才会走 spill。

一个能确认假说的实验

在修之前就能做，成本约 2 分钟：

# 造一个已知大小的超长单行
$f = "$env:TEMP\oneline.txt"
[IO.File]::WriteAllText($f, ("A" * 5MB))
# 在 DSH 里对 $f 执行一次 grep，同时用独立进程采样 RSS

如果 RSS 在 grep 期间出现一次陡增后宿主消失，你的"单次大分配"假说就确认了。如果 RSS 平稳地涨到几 GB 才死，那是累积 OOM，方向完全不同。

顺带说明：573 MB 这个 RSS 确实不像 OOM（Node 默认 heap 上限远高于此），所以我也倾向于单次分配 —— 但 573 MB 是最后一个采样点，死前那几十毫秒的峰值你还没看到。上面的实验就是为了抓到那个峰值。

建议的报告结构

把「证据」和「假说」分开写，并明确标注：

• 已验证：两次死亡都在超长单行处理期间，WER 为空（= abort 而非异常）
• 未验证：单次大分配（需要上面的 RSS 实验）
• 已知缺失：stderr 从未被捕获（你已修复，下次死亡会给出根本原因）

这样接手的人不会把未验证的假说当作结论去改错地方。

[cinast]

结案更新：假说全部被推翻——不是 OOM、不是 abort、也不是超长单行。

先谢这两条分析，推理本身是对的（无 WER 确实指向 abort 类路径、字节级截断确实是正确形状）。但我今天拿到了决定性证据，结论跟你我此前的方向都不一样。

决定性证据

给宿主加上 --inspect=127.0.0.1:9229，再用一个脱离宿主进程树的看门狗每 10 s 探测 http://127.0.0.1:3080/dgh-dashboard/，连续 2 次超时就用 CDP Debugger.pause 抓栈。三次连续抓取，6 帧完全一致：

commandContext            lib/reducers/command.js:74
commandTokens             lib/reducers/command.js:98
reduceGit                 lib/reducers/git.js:24
applySemanticReducers     lib/reducers/index.js:48
ctx.on.prepend            lib/index.js:284
processTicksAndRejections node:internal/process/task_queues:103

全部来自第三方插件 dsh-tool-result-trimmer@2.8.0——它挂在 tools/post-execute 上，每个工具结果都同步跑一遍。

关键读数：

• Debugger.pause 延迟 101 ms：主线程在跑 JS，不是阻塞在系统调用，也不是卡在分配；
• 进程 alive=1、RSS 平稳在 577–795 MB：没有任何"死前峰值"；
• 触发命令输出只有几 KB：cd ~/…/src/mailbox 2>/dev/null && sed -n '50,75p' tools.ts && grep -rn "args?.from" . | head -5。

也就是："超长单行 / 单次大分配"这条线可以整条划掉了。我此前也顺着它走，错了。

真正的根因

该插件 commandContext() 里一条嵌套量词正则：

/^cd\s+((?:[^\s'";&|<>`$()#]+|'[^'\n\r]*'|"[^"\n\r]*")+)\s*&&\s*(.+)$/

cd <较长目标> 2>/dev/null && … 这种形状（目标后面不是 &&）会让它失败后指数回溯。离线复跑同一函数：目标 16 字符 168 ms、20 字符 340 ms、24 字符 3 548 ms、39 字符 >10 s（被 timeout 杀掉），每 +4 字符约 ×8–10。

所以：进程既没崩也没 OOM，是主线程被一条正则锁死——UI 自然全黑、HTTP 探针全超时、工具结果没能落盘。你看到的"没有 stderr"不是因为 stderr 没接上，而是根本没有终止事件可写（最后是用户 taskkill）。

这对你三条建议意味着什么

1. stderr 重定向：仍然值得保留（成本≈0），但它对这类事故无效——因为这里根本没有"崩溃前落盘"的时刻，进程一直活着。
2. 按字节流式截断：作为独立加固仍然正确，且对另一类现场（上游请求被取代/流被中断）有用；只是它不是这次的原因。
3. 超长行保护：同理，纳入常规加固可以，但它修不了这次的问题。

真正该加进宿主的那一条

每个工具结果的同步处理要有时间预算，超时即熔断（跳过处理、保留原文、记一行 reducer-slow）。

理由：插件生态里"fail-open"几乎都只包 try/catch，而正则卡死不抛异常，只是永不返回——fail-open 抓不住它。这次事故里，一个宣传"防止 UI 卡死"的插件，恰恰把 UI 卡死了 20+ 次（已报上游：Jaylor-Wang/dsh-tool-result-trimmer#1、#2）。

如果 DSH 侧愿意，最小可行版是：tools/post-execute 的每个 handler 用 AbortSignal + N ms 预算包裹，超时即放弃该 handler 的输出并原样透传——这样任何一个第三方 reducer 写坏都不会再拖垮整个宿主。

我已按此把标题与结论更新，并附了抓栈方法（--inspect + 外部看门狗 + Debugger.pause），下次再有人遇到"宿主无响应"，5 分钟能定位到函数级。