Repository navigation
gc-native-roots has NEVER had a successful run: 3 of 4 arms fail with 3 distinct causes #7970
Description
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
- macos-14 zero-evacuation — the
gc_evacuation_liveness_assert.pyfailure 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. - aarch64-linux SIGSEGV under
PERRY_STACKMAP_WALKER=verify— a crash in the walker itself. - 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.
Activity
docs: record the filed follow-ups (#7970, #7971) in the gate notes
ci: fix the #7205 relapse on the scheduled gate arm, and reap dead PR…
ci: repair three broken gates — Windows cp1252, llvm-inprocess vacuou…
test(gc): run both aarch64 stack-map walkers over a frame we chose
fix(gc): the aarch64 fast stack-map walker misread every SVE-shaped p…
proggeramlug commentedon Aug 13, 2026
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 commentedon Aug 13, 2026
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.
proggeramlug commentedon Aug 13, 2026
Closing on the issue own acceptance criterion: a complete four-platform gc-native-roots run now exists.
Run 31731936936 on exact PR #8045 head 06a3a07 completed successfully across:
Run: https://github.com/PerryTS/perry/actions/runs/31731936936
That exact PR head was independently audited and merged; current main a9a99d8 contains the landing. This closes the umbrella failure report. Any future regression should be filed against the newly green baseline with its specific arm and oracle.