Repository navigation
gc: two rooting gap tests crash on macOS under PERRY_NO_AUTO_OPTIMIZE=1 while Linux passes them (untriaged) #7606
Description
Found in passing during #7599's known-failures audit, on the shared dev Mac
(macOS arm64, perry-dev profile, current main of 2026-08-08):
test_gap_gc_rest_argument_rooting and
test_gap_gc_same_module_call_argument_rooting crash on macOS when compiled
with PERRY_NO_AUTO_OPTIMIZE=1, while Linux (the gap_snapshot baseline
platform) records both as passing.
Not yet triaged — this issue exists so the observation is not lost. Three
things whoever picks it up should know:
- These are gc rooting acceptance tests (the gc(layer 3): from-space quarantine catches 55 stale dereferences across the gap suite — the instrument is in CI but aimed at one synthetic fixture #7341 family), so a platform-
split crash is potentially a real macOS-only rooting hole, not a harness
quirk — the auto-opt and no-auto-opt runtimes differ in feature set and
link layout, and the no-auto-opt arm is the one ordinaryperry compile
users get when the auto-opt path is bypassed. test_gap_gc_same_module_call_argument_rootinghas crashed spuriously
before — during a disk-full window on 2026-08-07 it recorded acrashthat
re-ran 10/10 clean afterwards (fix(runtime): a Map/Set subclass in a base-typed binding was read as a raw header (#7570) #7573's report). First step is therefore
reproduce N/N on a healthy machine before believing it; the test(parity): make known_failures.json a ratchet, not a suppression list (#7582) #7599 agent
saw it in passing, not under controlled conditions.- If it reproduces, the instruments are
PERRY_GC_ZEAL=1 PERRY_GC_PROTECT_FROMSPACE=1 PERRY_GC_DIAG=1— but note gc: zeal + compiled loop polls performs zero copying minors on compute-only benches — green instrument runs may be vacuous #7604: on
compute-only shapes the zeal recipe can arm without ever firing, so check
retired_set=lines actually appear before trusting a clean run.
Activity
proggeramlug commentedon Aug 10, 2026
Closing as not reproducible on current
main(v0.5.1432), with the instrument proven live rather than merely quiet.Baseline, the issue's own configuration:
test_gap_gc_rest_argument_rootingPERRY_NO_AUTO_OPTIMIZE=1test_gap_gc_same_module_call_argument_rootingUnder the full investigation pairing —
PERRY_GC_ZEAL=1 PERRY_GC_PROTECT_FROMSPACE=1 PERRY_GC_PROTECT_FROMSPACE_DEPTH=800(depth 800 because #7154's own reproducer needed it; the default of 4 is far too small for real code):Since #7604 that verdict line exits 70 if forced collections or copying minors are zero, so a clean exit here is a positive statement that the collector ran — 379 and 749 evacuating minors relocating 115,536 and 231,012 objects, under an
mprotected from-space quarantine, with no fault.The disk-full precedent this issue cites (#7573) was also checked: free space stayed at 39 GB throughout, never close to full. Not a factor.
One incidental result worth recording, since it validates #7729 in the field: those same two tests previously reported 9,653 and 19,253 forced collections. They now report 379 and 749 — with
moved_objectsessentially unchanged (115,536 vs 115,728; 231,012 vs 231,348). Same relocation work, ~1/25th the collections. That is exactly what allocation-paced zeal was supposed to do.