Bug：内置 ugrep.exe 7.5.0 遇到含 {0,60} 区间的正则无限挂死（内存 5GB+、磁盘 100%）

Bug：内置 ugrep.exe 7.5.0 遇到含 {0,60} 区间的正则无限挂死，内存涨至 5GB+、磁盘 100%

环境

• Windows 11 x64（build 26200），ZCode 桌面版（2026-08-29 当日最新版）
• 内置搜索工具：resources\tools\ugrep\ugrep.exe
  • 版本：ugrep 7.5.0 WIN64 +sse2; -P:pcre2jit; -z:zlib,bzip2,zstd,brotli,7z,tar/pax/cpio/zip
• ZCode 的 bash 启动脚本会把 grep 命令重定向到该 ugrep（附加 -G --ignore-files --hidden -I --exclude-dir=...）

现象

会话中智能体执行一条普通的 grep 搜索后无限挂死：

• ugrep.exe 内存涨到 4.5–5.5 GB，9 分钟不回落，只能手动结束进程
• 系统内存 94%、磁盘 100%（内存吃满引发换页风暴，System 进程换页 I/O 45 MB/s）
• 整机卡顿；而实际被搜索的文件只有 31 KB

最小复现

ugrep.exe -G -E "[a-zA-Z$_]{1,20}\(\{[^}]{0,60}file[^}]{0,60}\}\)" 任意文件

• 任意文件都会挂死，包括只有 16 字节、不含任何括号的纯文本——说明是正则模式本身触发，与文件内容无关
• -G（BRE）和 -E（ERE）模式都复现；带不带 -o 都复现；与 --ignore-files / --hidden 无关
• 5 秒超时强杀，退出码 124，输出 0 字节（不是慢，是完全不动）

定位

把原正则拆成三段分别测，元凶是第一段：

[a-zA-Z$_]{1,20}\(\{[^}]{0,60}file[^}]{0,60}\}\)

把量词区间改小后立即恢复正常（659 ms 返回，rc=1 无匹配）：

• {0,60} → {0,5} ✅ 正常

判断为该捆绑版本 ugrep 对「多个长区间量词相邻组合」的灾难性回溯（或等价的病态匹配路径）。

影响

编码智能体在会话里很自然地会生成 {0,60} 这类区间正则（本例就是模型从压缩 JS 里提取上传接口调用时写出来的）。一旦命中：挂死的不只是那条命令，内存被吃满引发换页风暴，用户整机假死，且很难自行定位到 ugrep。

建议

1. 升级捆绑的 ugrep 至修复版本（上游：https://github.com/Genivia/ugrep）
2. 或在 ZCode 封装的 grep 函数里检测超长 {n,m} 区间，超过阈值时回退到 GNU grep
3. 用户侧临时救急方案：任务管理器结束 ugrep.exe，无副作用（下次搜索会重新拉起）

Start by reproducing the command against resources\tools\ugrep\ugrep.exe, then inspect the ZCode bash startup script's grep redirection and bundled ugrep version. Compare the reported interval patterns and proposed upgrade or fallback paths; done means the minimal reproduction no longer hangs or exhausts system resources.