[Bug] dsh web 反复 OOM：dsh-fs-local listDirectory 跟随符号链接环无限遍历

[noel-psc]

[Bug] dsh web 反复 OOM 崩溃：dsh-fs-local listDirectory 跟随符号链接环无限遍历（displayPath 无限增长）

现象

• dsh web 启动后 12~19 分钟崩溃：V8 堆持续增长直至撞上限，FATAL ERROR: Ineffective mark-compacts near heap limit / Reached heap limit Allocation failed - JavaScript heap out of memory，每次留 200~500MB 核心转储
• 换更大的堆上限（--max-old-space-size=6144）只能延迟崩溃，不能解决（实测 6.3GB 上限下仍涨到 6.1GB 后崩溃）
• 主线程 CPU 常驻 140~180%，空闲时也在跑
• 与导入会话数量无关：删光全部导入会话与副本后，遍历与内存膨胀依旧

环境

• Fedora 44 / x86_64，Node v24.15.0，dsh v0.1.0-rc.6
• 挂载：Steam 的 Proton 前缀（/game/SteamLibrary/steamapps/compatdata/*/pfx/）、Podman 容器 overlay、xdg-document-portal（/run/user/1000/doc）

根因定位（已抓到实锤）

dsh-fs-local/lib/index.js 的目录列举对每个子项做 realpath + stat（跟随符号链接）：

listDirectory (line ~294 对每个子项)
  └─ resolveListedChildTarget → resolveLocalTarget → realpath(displayPath)
  └─ probe → stat(targetKey)   // stat 跟随符号链接

当遍历器（浏览器侧目录选择器，走 host.listDirectory RPC）递归下钻时，没有 visited/环检测，遇到以下符号链接环即无限循环：

1. Proton 前缀自环：.../compatdata/1325860/pfx/dosdevices/s: → /game/SteamLibrary/steamapps（s: 是到 steamapps 的符号链接），而 steamapps/compatdata/1325860/pfx/dosdevices/s: 又指回 steamapps —— 六层自环
2. xdg-document-portal 树：/run/user/1000/doc/by-app/<app>/<hash>/...（沙箱应用可见文档树，FUSE 桥接，天然带环）

每次循环 displayPath 由 join(parent.displayPath, name) 无限拼接（不规范化），导致：

• 堆里留下重复数百次的路径片段字符串（heap snapshot 实锤：/compatdata/1325860/pfx/dosdevices/s: 重复 ~200+ 次，单条 9MB+）
• 每 ~30 秒爆发 ~1GB 分配（Runtime.getHeapUsage 实测 977MB → 5397MB → 813MB），GC 追不上就 OOM

触发条件：仅当浏览器客户端连接时（headless 旁路实例无客户端，内存稳定在 ~100MB 不涨）。

证据

• CPU profile（45s）：listDirectory/resolveListedChildTarget/resolveLocalTarget/join/realpath 占非空闲样本绝大部分
• Debugger 暂停抓栈：多次命中 listDirectory → resolveListedChildTarget → resolveLocalTarget → realpath，参数为 /run/user/1000/doc/by-app/moe.launcher.an-anime-game-launcher/.../keil/Objects 等深路径
• heap snapshot diff：增长全部是路径片段字符串（/compatdata、/pfx、/dosdevices、/s: 等）
• 宿主机验证：s: → /game/SteamLibrary/steamapps，环真实存在

临时修复（本地补丁）

在 dsh-fs-local/lib/index.js 打了两个防护：

1. resolveLocalTarget 加路径深度护栏：displayPath 超过 128 层直接拒绝（FS_IO_ERROR）
2. listDirectory 子项自环检测：子项 realpath 结果 == 当前目录 targetKey 时标记为 other 不返回 directory

建议修复（请官方确认）

1. 遍历器维护 visited realpath 集合：任何递归目录遍历记录已访问的 targetKey，重复即剪枝
2. 或 listDirectory 对符号链接目录默认不返回 type: "directory"（或返回 isSymlink 标志由调用方决定）
3. 或对 displayPath 增长做上限

复现

dsh web   # 打开浏览器 GUI
# 观察：主线程 CPU 140%+，堆每 30s 振荡 ~1GB，12-19 分钟后 OOM

（机器上存在 Proton 前缀或容器 overlay 即可触发；/game/SteamLibrary/steamapps/compatdata/*/pfx/dosdevices/s: 是标准 Proton 布局）

[ylwl1997]

The heap dump + Proton dosdevices/s: cycle is a solid root cause: dsh-fs-local listDirectory does realpath+stat per child with no visited set, then the web picker recurses, so displayPath grows without bound. That also explains why raising --max-old-space-size only delays the crash, and why a headless instance without the GUI picker stays flat.

Until a visited-targetKey prune (or “symlink dirs are not type: directory”) lands, the operator workaround is to keep the web workspace and file picker off cyclic trees:

• Proton prefixes (…/compatdata/*/pfx/dosdevices/)
• xdg-document-portal (/run/user/*/doc)
• container overlay / FUSE app dirs

Point dsh web at a small project directory that does not contain those mounts, and avoid browsing them in the sidebar. Your local depth-128 guard plus “child realpath == current targetKey → not a directory” is a reasonable band-aid; the visited-set on targetKey is the one that actually terminates arbitrary-length cycles (a self-loop check alone will not catch the six-layer s: steamapps cycle).

[noel-psc]

Thanks — agreed on the visited-targetKey prune (or "symlink dirs are not type: directory") being the proper fix. I'll keep the web picker off the cyclic trees and test an upstream fix once it lands.