Go cgo_stale 测试为何在 ppc64 构建器失败：缓存陈旧与资源终止怎么区分

Go 官方仓库最近收集了一类很容易误判的构建失败：TestScript/cgo_stale 在 GOARCH=ppc64 构建器上执行 go build -x . 时，最后停在 pkg/tool/linux_ppc64/compile，输出 signal: killed。测试名里虽然有 stale，但这条日志首先证明的是编译进程没有正常完成，还不能证明缓存判断错了。

先把“缓存陈旧”与“编译资源终止”当成两条证据链：只有看到缓存状态变化、cgo 重建和最终复查结果，才适合给出根因判断。

从 cgo_stale 的失败现场先看失败发生在哪里

官方 issue #81328 的模式是 pkg == "cmd/go" && test == "TestScript/cgo_stale"，它只是把相同表面失败收集到一个 Watchflakes issue。示例日志先打印出 GOARCH=ppc64，随后执行 go build -x .，中间能看到 cgo 处理 m.go，最后才是 ppc64 版本的 compile 被杀死。

这个顺序很关键。cgo_stale 这个名字描述的是测试覆盖的缓存场景，不是每次失败的根因。若日志没有走到“构建完成后再次判断 stale”的位置，就不能把缓存断言和编译进程终止混成一个结论。

为什么 signal: killed 不能单独证明缓存陈旧

signal: killed 的直接含义是被调用的编译进程没有以正常退出状态结束。它可能与构建器资源、系统终止或其他外部上下文有关；这条信息本身没有告诉我们 GOCACHE 中哪个对象失效，也没有告诉我们 runtime/cgo 是否已经完成重建。

官方 Watchflakes 文档也把这类 issue 定义为“表面 flaky 失败”的聚合入口：模式命中后贴入已有 issue，没有命中才新建模式。它解决的是收集和归类，不是替维护者完成根因分析。因此，issue 标题、测试名称和一条末尾信号都只能算线索。

用环境、缓存与工具链日志复核构建边界

官方 cgo_stale 脚本先设置唯一的 CGO_CFLAGS=-DTestScript_cgo_stale=true，再检查 stale runtime/cgo。后面它将 GOCACHE=$WORK/cache 指向新缓存，运行 go build -x .，要求日志出现针对 runtime/cgo 的 cgo 调用；下一次构建又要求不再重复调用。这里验证的是输入变化、缓存对象和重建次数的关系。

排查 ppc64 失败时，可以沿同一思路读日志，但不要把“新缓存”当成资源修复。先记录 GOARCH 与构建器名称，再确认 CGO_CFLAGS 是否改变，接着看 GOCACHE 路径和 runtime/cgo 是否完成；最后区分 pkg/tool/linux_ppc64/cgo 与 pkg/tool/linux_ppc64/compile。当前 issue 的例子停在后者，这正是需要补充资源上下文的信号。

把一次失败改写成可复查的证据链

给 issue 留评论或复盘构建器时，建议把结论写成“现象—证据—边界”，而不是一句“缓存坏了”。最小记录可以这样整理：

1. 现象：写清 TestScript/cgo_stale、构建器、GOARCH=ppc64 和失败命令。
2. 证据：保留 go build -x . 的关键片段，标出 CGO_CFLAGS、GOCACHE、cgo 和 compile。
3. 边界：如果没有完成 cgo 重建和后续 stale 复查，就把结论写成“需要补充构建器资源或完整日志”，不要定性为缓存陈旧。

这样写的好处是，下一位维护者可以只补缺失的一段上下文，而不是重新猜测测试名称。若同一构建器反复在 compile 阶段被终止，再去对照构建器资源、系统日志和相邻失败；若完整跑完测试后只在带新 flag 时触发一次重建，才有足够证据讨论缓存状态。

常见问题：cgo_stale 排查后还要看什么

清空 GOCACHE 能证明是缓存问题吗？

不能。新缓存可以隔离旧对象，帮助观察重建关系，但它不能解释 ppc64 的 compile 进程为什么被终止。

为什么要保留 go build -x 的输出？

因为它能把 cgo、编译器、参数和包路径放在同一条证据线上，便于判断失败阶段，而不是只看测试摘要。

Watchflakes issue 可以直接当作根因结论吗？

不可以。它适合持续收集表面相同的失败；根因仍要靠完整日志、构建器上下文和可重复的缓存状态复查。

这次判断的核心只有一句：stale 是测试要验证的状态，signal: killed 是一次未完成的进程事实。把两者拆开，再按架构、输入、缓存和工具链阶段补证据，才不会把资源终止误报成缓存故障。