gc-native-roots has NEVER had a successful run: 3 of 4 arms fail with 3 distinct causes

[proggeramlug]

gc-native-roots.yml is listed in #7966 as having "NO successful post-merge run in the sampled window". Checking it, the window is not the limit:

gh run list --workflow=gc-native-roots.yml --status=success --limit 50
# (empty — all branches, all events)

It has never had a single successful run. This is a red gate, not a starved one, and it should be triaged separately from #7966's scheduling problem.

Evidence

Run 31405431962 (push/main, sha bf8af0e0f, 2026-08-10) — three of four arms fail, with three different root causes:

arm	result	cause
ubuntu-latest x86-64 ELF	success	—
ubuntu-24.04-arm aarch64 ELF	failure	exit 139 (SIGSEGV), then ::error::01_nursery_churn crashed under PERRY_STACKMAP_WALKER=verify
windows-latest x86-64 PE	failure	exit 101 (Rust panic), then exit 2
macos-14 aarch64 Mach-O	failure	gc_evacuation_liveness_assert.py: "the forced-evacuation arm evacuated NOTHING (0 copying minors, 0 objects copied)… No [gc-copy-minor] line at all — every collection in this run was a FULL cycle"
gc-native-roots-complete	failure	by design; requires every arm

It is also starved on top of that — the aggregator for that run only completed 2026-08-12T12:09Z, ~44h after creation. #7969 fixes the starvation; it does not touch any of the three failures above.

Why the macOS arm is worth looking at first

Its symptom — "every collection was a FULL cycle, zero copying minors" — is the same shape as #7965.

Flagging this as a hypothesis, not a conclusion: it cannot be the same bug. This run is at bf8af0e0f on 2026-08-10, two days before #7902 (1bd5eeb6b) merged. But "the collector stopped running copying minors" has now surfaced twice in three days from two different causes, and this arm has been sitting on the first instance unread since at least 08-10 because nobody was reading a gate that has never been green.

That is also a direct instance of CLAUDE.md hazard 4 wearing a new hat: the gate is genuinely red, reports red, and blocks nothing — it is not in branch protection's required contexts, so a red result is indistinguishable from the noise of a starved queue.

Suggested triage order

1. macos-14 zero-evacuation — the gc_evacuation_liveness_assert.py failure is the one with a real GC claim behind it, and it is the arm whose subject overlaps the live perf(gc): main regressed the retain cluster 2.2-4.8x — retain now runs 2 full collections where it ran none (suspect #7901/#7902) #7965 investigation.
2. aarch64-linux SIGSEGV under PERRY_STACKMAP_WALKER=verify — a crash in the walker itself.
3. Windows panic (exit 101) — likely the most isolated.

Each is plausibly independent; they should probably not be fixed as one change.

Note on promotion

Once green, this is a candidate for branch protection — but per CLAUDE.md, run it once green first, then promote. Promoting a never-green gate would block every open PR.

Found while diagnosing #7966. Related: #7969.

[proggeramlug]

Windows audit update (2026-08-13): the PE arm's download bug was fixed in #7986, the LLVM static-link failure was replaced with the official archive's LLVM-C dynamic import in merged #8017, and PR #8018 packages that runtime beside perry.exe/npm installs. The aarch64 walker mismatch was fixed in #7997. All four arms are now expected green, but I am leaving this umbrella open until one complete gc-native-roots run proves that end to end; per the issue's own gate-liveness standard, code/comments are not a substitute for a green run.

[proggeramlug]

Follow-up from the Windows audit: #8028 fixes the Windows arm's current pre-probe failure. Git Bash was handing tar the native D:... RUNNER_TEMP path; the runner parsed D: as a remote host despite the existing --force-local attempt. The PR normalizes the archive/root paths through cygpath before curl/tar. Keeping this umbrella open until all four arms are green.