Repository navigation
gc-matrix: intermittent output mismatch on test_gap_repsel_gc_stress x safepoint_minor (1 in 11, 10/10 clean in isolation) #7678
Description
Summary
test_gap_repsel_gc_stress × safepoint_minor produced an output mismatch in a full 58-file scripts/gc_repsel_matrix.sh --arms pr run, and 10/10 clean when the identical binary is re-run in isolation with the identical env. It is intermittent, it is untriaged, and it is on the arm the matrix leans on hardest.
Evidence
Full run (58 files x 7 PR arms, --pressure 8, node 26.5.1, release compiler):
FAIL test_gap_repsel_gc_stress (output-mismatch cycles=52 evacuated=0 scavenged=38184 reclaimed=799294640)
summary: PASS=341 UNVER=64 XFAIL=0 FAIL=1
Isolated re-run, same binary (compiled with PERRY_GC_MOVING_LOOP_POLLS=1), same run env
(PERRY_GC_HEAP_LIMIT=8 PERRY_GC_MOVING_LOOP_POLLS=1 PERRY_GC_TRACE=1 PERRY_GC_DIAG=1), 10 runs:
10 ok, 0 bad, of 10
with copied_objects per run at 415,450 (x8), 415,453 and 303,205 (x2) — so the arm is live on every run and the collection schedule itself varies run to run.
Note the mismatching run also scavenged far less than the clean ones (38,184 vs ~415,450), i.e. it took a different collection schedule, not merely a different outcome under the same one.
Why it is worth its own issue
safepoint_minor is described in gc_repsel_matrix.sh as "THE SOUND RELOCATING ARM, and what keeps the #6993 defect class reachable per-PR while #7161's stopgap holds." It compiles and runs with PERRY_GC_MOVING_LOOP_POLLS=1 — the configuration #7161 turned off by default precisely because of #7154's use-after-free. An intermittent wrong-output on that arm is consistent with that open class still biting at a low rate, which is exactly the thing the arm exists to surface.
The last main gc-stress run (31240304595) reported FAIL=0 over 22 arms, so this is a low-rate sampling difference rather than a new deterministic break — which is what makes it easy to lose.
Deliberately NOT triaged
It is not in test-parity/gc_repsel_triage.txt and should not be added until it is root-caused. Triaging a red nobody has explained is how a real defect becomes permanent furniture — and test-parity/gc_repsel_triage.txt entries are supposed to name a cause, not a symptom.
Suggested first step
Capture the mismatching run's stdout and diff it against the oracle to find which line diverges (the harness discards the diff today; only output-mismatch survives into the cell evidence). A per-cell saved diff for FAIL cells would make this class self-documenting, and is cheap — the harness already writes both files.
Activity
proggeramlug commentedon Aug 10, 2026
Closing as not reproducible, on the arm's own harness rather than a hand-rolled approximation.
scripts/gc_repsel_matrix.sh --arms safepoint_minor --filter test_gap_repsel_gc_stress, six consecutive rounds on currentmain(v0.5.1432): 6/6 PASS, 0 FAIL, 0 UNVER, with the arm reportinglive 1/1 counter=44806every time.liverather thanUNVERis the part that makes this meaningful — the matrix distinguishes "output matched" from "output matched and the arm actually collected", and an inert arm would be a pass that exercised nothing. This issue reported 1-in-11; six clean rounds is not a proof of absence, but combined with the evidence below it is enough to stop tracking it.An earlier pass got much further and found the same thing at greater scale: 280+ runs with zero mismatches, across four configurations — 120 serial with
PERRY_NO_AUTO_OPTIMIZE=1, 100 serial with a real auto-optimize build (matching how the harness actually links), 60 across six rounds of 10-way parallel invocation on a box at load 53 (a deliberate proxy for the matrix's ownxargs -Pfan-out, since a parallel-only race was the obvious hypothesis), and one direct harness invocation. Every run reported the identical schedule:copy_minor_runs=53 copied_objects_total=44804, with no variance at all — notably more deterministic than this issue's own isolated re-runs, which hadcopied_objectsvarying across 415450 / 415453 / 303205.That last detail is the strongest signal: the nondeterminism this issue was filed about is itself gone. The scheduling now reproduces exactly, run to run, serial or parallel.
Reopen with the
copied_objectsvalue and thexargs -Pwidth if it returns — those two are what distinguish a real schedule race from an inert arm.