# GCC 偶发子进程启动失败：定位与恢复

日期：2026-09-13；分支：`system-optimization`。用户要求在元件语义修复过程中继续定位并处理偶发 GCC 错误。

## 已定位的事实

本机 GCC 8.1 本体能运行，但在启动 `cc1.exe` 的过程中偶发失败。详细 `-v` 记录已经打印了实际存在的绝对路径；添加编译器目录到 PATH 后，192 次串行/并发对照中的一组仍有一次失败，因此不能把 PATH 补全或并发关闭当成已证明的根因修复。

对本轮自行启动的 GCC 诊断进程设置临时 Windows 调试断点，捕获到一次同类失败：

```text
CreateProcessA return = 0
GetLastError = 5 (ERROR_ACCESS_DENIED)
application = F:\Projects\mingw64\bin\..\libexec\gcc\x86_64-w64-mingw32\8.1.0\cc1.exe
gcc exit = 1
```

该样本是“拒绝访问”，不是“找不到 GCC 本体”。GCC 的 Windows 实现会把多种创建进程错误映射成 ENOENT，使终端只显示 `CreateProcess: No such file or directory`；这一信息损失也见 [GCC 官方讨论](https://gcc.gnu.org/pipermail/gcc-help/2025-May/144184.html)。

只读核查发现：cc1.exe 存在，普通用户有读取/执行权限，没有 Zone.Identifier 下载标记，未查到相关 Defender/Code Integrity 拦截事件。诊断进程不在作业对象中。**这些证据尚不能锁定 Windows 内部为何临时拒绝此次创建进程，也不能证明所有同类文本都对应错误 5。没有修改 ACL、安全配置、已安装 GCC 或系统 PATH。**

同时捕获到独立异常：`gcc --version` 有时退出码为 0，但 stdout 为空；旧代码直接取首行，产生 `IndexError`，进一步把工具链问题变成了不明确的后端异常。

## 后台修复

1. 保持 `SIMULATION_NATIVE_CC`/PATH 和 `SUNDIALS_ROOT` 的原查找规则，不写入任何本机绝对路径。Windows 将选中的编译器目录放入该子进程自己的 PATH；不修改后端全局环境。Linux 保留所配置命令及环境，包括依赖 argv[0] 的编译器包装器/符号链接。
2. 正式构建与启动自检统一使用有效的空标准输入、受控的标准输出/错误管道、关闭无关句柄继承；Windows 隐藏编译器窗口。
3. 正式构建只对已识别的 GCC 子进程启动错误、特定 Windows 临时进程错误，以及空编译器身份输出进行恢复。最多重试 5 次，间隔 0.05、0.1、0.2、0.35、0.5 秒。成功立即返回；失败日志保留，每次重试可追踪。
4. C 语法错误、未定义符号等链接错误、缺失编译器和超时不走上述重试。版本/目标查询必须有有效输出，空版本不会再触发 IndexError。
5. 启动自检的整轮重试仍由既有后台状态机管理：首次检测加最多 5 轮，编辑器可用，最终失败才展示详细错误。自检预处理/编译/链接命令不再额外叠加一层整轮重试；编译器身份查询可使用命令级恢复。
6. 正式构建记录 `compilerLaunchRetries`（构建命令的次数，独立的版本查询恢复在服务器日志中记录）；最终编译失败保留命令、退出码、stdout/stderr、尝试次数等详情。启动自检明确描述为“GCC 已启动，但无法启动编译子进程”，避免再让用户误以为只需重配 gcc 路径。

这修复了应用把一次可恢复启动失败直接判为仿真失败的行为；**没有声称消除了 Windows 层所有拒绝访问的根源**。若六次启动仍失败，仍会如实报错，不更换编译器、不绕过系统安全限制。

## 验证

- 修复后 **128 次、并发度 4 的真实预处理调用全部完成**。期间再次捕捉到 1 次相同 CreateProcess 失败，自动重试一次成功，无需手动重启后端。
- **连续 10 次完整启动自检全部通过**，每次均执行预处理、编译、SUNDIALS 链接和最小 BDF 程序运行，未使用模型缓存。
- 进程专项测试覆盖瞬时错误恢复、重试上限、日志保留、真实语法/链接错误不重试、空版本、超时/缺失文件、环境隔离、Linux 分支，以及最终身份查询失败的完整自检详情；最后检查见 `final-process-detail-tests.log`。
- 元件与启动自检综合 43 项回归通过；最终编译进程/启动自检/历史合同组合 25 项通过；最终元件/目录检查 14 项通过。后续四路真实构建过程中再出现两次启动抖动，也都自动恢复并完成仿真。独立数值探针曾有一次空输出导致测试失败，保留记录并完整重跑通过；没有据此扩大为任意仿真进程的自动重跑。
- Linux 适配由跨平台分支测试覆盖；本次未登录 Linux 服务器做实机验证。

证据目录：`test/component-semantics-20260913/`。原始对照为 `gcc-probe.json`；原始 Windows 错误码为 `gcc-debug4.log`；恢复压力测试为 `launch-verification.json`；专项为 `compiler-process-tests.log`、`final-launch-and-contract-tests.log`。调试程序仅留在被忽略的 test 目录，不加入生产程序，也未修改磁盘上的编译器。

修改后需要后端进程加载新代码。已有运行进程不会因磁盘文件变更自动得到新逻辑（除非本身启用了 reload）。