kill() on ConPTY can hard-kill an unrelated live process up to 5s later via bare-PID fallback in _getConsoleProcessList timeout
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 45/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- node.js, typescript
调研方向
从 lib/windowsPtyAgent.js 中的 WindowsPtyAgent.prototype.kill() 和 _getConsoleProcessList() 开始，然后追踪 ConPTY non-DLL timeout 以及 winpty 分支中关于 PID reuse 的注释。重现 issue 中描述的 close/list race；完成的标准是，所选择的 close-without-enumerate 或 attach-before-close 行为能够避免 delayed bare-PID kill，同时保留控制台进程清理。
由索引模型根据 Issue 内容生成。
描述
In lib/windowsPtyAgent.js, WindowsPtyAgent.prototype.kill() (ConPTY,
non-DLL branch) calls this._getConsoleProcessList().then(list => list.forEach(pid => process.kill(pid))) without awaiting it, then
synchronously closes the pseudo-console. The forked list child therefore
always loses the race (console already closed), no message ever arrives,
and the 5s timer runs agent.kill(); resolve([_this._innerPid]) — "just send
back the shell PID".
Up to five seconds after kill(), the library hard-kills that PID by bare
number. The owning application has typically already reaped the shell by then
(in our case: tree-killed and ESRCH-confirmed). If the OS recycled the PID in
the interim, the kill lands on an unrelated live process — silently (ESRCH
swallow on success-path failure only; a live victim reports nothing).
Rehearsed, not inspected (plain node, wrapped in-process process.kill):
spawn pty shell (pid 11164) -> kill() -> wrapped process.kill(11164) fires
at dt=5.0s post-return; shell ESRCH-confirmed gone. Locally we resolve []
instead (safe here only because our app kills its own tree with image-verified
fail-closed kills plus taskkill); restoring the fallback brings the call back
(both directions rehearsed). Your own comment in the winpty branch of the same
function names the hazard: "Process IDs can be reused as soon as all handles
to them are dropped."
Why resolve([]) is NOT proposed as the upstream fix: for any consumer relying
on node-pty itself to kill the console process list, dropping the fallback
reintroduces Microsoft/vscode#26807 (detached node servers surviving kill()).
It is valid only where the caller owns teardown. The proposals below preserve
the list-kill for those consumers.
Ask (two separable options):
- Close-without-enumerate option for
kill()(callers that already kill
their own tree don't need the console-list fork at all). - Alternatively, attach-before-close: await the list before
ClosePseudoConsole so a timeout genuinely means a dead console.
Cross-reference: downstream we consume this via
homebridge/node-pty-prebuilt-multiarch, whose rebuild would pick up a fix
here. No PR attached — issue only.
- 主要语言
- TypeScript
- 星标
- 2k
- 派生
- 343
- 平均合并
- 22 小时 24 分钟
- 30 天内合并 PR
- 6
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
microsoft/node-pty 的其他 Issue
-
spawn drops an own `__proto__` environment entry可能已有人在做 @nikolay-dementiev 于 2 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
ConPTY/TSFN exit callback aborts the process during environment teardown — fixable with NODE_API_SWALLOW_UNTHROWABLE_EXCEPTIONS (same root cause as #904)可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 2/5 1-3 小时 新手友好度 76/100
microsoft/node-pty#951 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
查看 microsoft/node-pty 的全部 Issue
相似的 Issue
-
backend priority:P3 privacy-fix
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
bug desktop v3 windows
难度 2/5 1-3 小时 新手友好度 65/100
esengine/DeepSeek-Reasonix#13697 · 1 条评论 ·
维护者通常 1 天内回复
-
area:security documentation effort:S priority:P2
难度 2/5 1-3 小时 新手友好度 65/100
维护者通常 1 天内回复
-
app:web meta:ops
难度 2/5 半天 新手友好度 78/100
osu-tournament-rating/otr#1113 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 82/100