gc: test_gap_repsel_gc_stress SIGSEGVs deterministically in 12 matrix arms under #7019's default-on moving minor (PASS -> FAIL)

[proggeramlug]

Split out of the post-#7019 matrix re-measurement. New red, attributed to #7019 by A/B on the same source and compiler.

Symptom

test_gap_repsel_gc_stress — the corpus member deliberately built to be GC-live — SIGSEGVs (exit 139) in 12 of 20 arms of scripts/gc_repsel_matrix.sh --arms all --pressure 8. It produces zero stdout lines against an oracle of 7.

The failing arm set is exactly the 12 arms that carry PERRY_CONSERVATIVE_STACK_SCAN=off (directly, or via the %E% evacuating base): evac_minor, force_evac, force_verify, cons_scan_off, cons_scan_off_force, loop_polls, and the six rep_*_off arms. The other 8 arms pass.

This is a PASS → FAIL transition, not an inert cell going red. test-parity/gc_repsel_triage.txt records this file's cons_scan_off cells as green hard gates since #6951, and the last pre-#7019 full matrix (#7015, base 4ad27a15b) had FAIL=20 consisting only of the two #6981 rows.

Attribution — measured, not inferred

Same source, same compiler binary, A/B'd through #7019's own kill switch with PERRY_GC_MOVING_LOOP_POLLS=0 set at both compile and run time (the runtime and codegen halves must match — see the comment on gc_moving_loop_polls_enabled). Config PERRY_GC_HEAP_LIMIT=8 PERRY_GC_INCREMENTAL=0 PERRY_CONSERVATIVE_STACK_SCAN=off:

build	exit codes (5 consecutive runs)	output
default (#7019 on)	139 139 139 139 139	truncated
PERRY_GC_MOVING_LOOP_POLLS=0 (#7019 off)	0 0 0 0 0	byte-exact vs node 26.5.0

Deterministic, 23/23 crashes observed with #7019 on across repeated batches; 0/11 with it off. Reproduced on two hosts and by the matrix harness itself (exit=139 cycles=27 moved=1727552, identical across all 12 arms and across re-runs).

Where it dies

Immediately after a successful evacuating minor — the last three stderr lines before the fault:

[gc-copy-minor] eligible=true fallback=none
[gc-copy-minor] ran copied_objects=101215 copied_bytes=4594776 promoted_objects=44933 promoted_bytes=2039816 freed_bytes=14384
[gc-step] pre_in_use=10790856 post_in_use=10776472 sweep_freed=14384 block_reclaim=14384 pct=0% step=1073741824→1073741824
[gc] cycle

So relocation completed and the mutator faulted afterwards — the shape of a survivor reference that was moved but not rewritten, or a root the copying minor did not see. Note promoted_objects=44933: this cycle both copies and promotes, so the old-gen handoff path is in play as well.

Why this one matters more than a normal corpus row

gc_stress is the only corpus member that holds each representation-selected local live across escaping allocation churn heavy enough to reach the collector. With it crashing, the 12 arms that were the strongest evidence in the matrix now assert nothing about representation safety under relocation — they assert only that the process dies.

Environment: origin/main @ 4340bffc9, release build, macOS arm64 (reproduced on both a 64 GB and an 8 GB host), node 26.5.0 pinned.

Related: #6981 (same PERRY_CONSERVATIVE_STACK_SCAN=off discriminator, different rows), #6982 (a different, intermittent gc_stress SIGSEGV with the conservative stack scan ON), #7019.

[proggeramlug]

Root-cause investigation: the loop-back-edge hypothesis is refuted; the array-growth forwarding stub is the necessary condition

Measured on origin/main @ 775e29193 (i.e. 4340bffc9 + #7020), release, macOS arm64, node 26.5.0 pinned, in a dedicated worktree/target.

1. Reproduced, and it is a heap corruption, not a mutator UAF

test_gap_repsel_gc_stress under PERRY_GC_HEAP_LIMIT=8 PERRY_GC_INCREMENTAL=0 PERRY_CONSERVATIVE_STACK_SCAN=off: 8/8 SIGSEGV. The symbolised stack is byte-identical across every crash:

main +860
js_array_push_f64_grow +180
js_array_grow +580
arena_alloc_gc_old +100
Arena::alloc +124
gc_check_trigger +904
gc_collect_full_mark_sweep_with_trigger +732
GcCycleState::step +16300
gc::trace::ValidPointerSetBuilder::step +460
alloc::raw_vec::RawVec::grow_one +60
RawVecInner::finish_grow +88
_mi_theap_realloc_zero +272          <- SIGSEGV
EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x401080082201  (esr 0x92000005: byte read, translation fault)

The fault is inside the GC's own Vec growth, in mimalloc's realloc, on a corrupted pointer. So the collector is not dereferencing a moved object — the malloc heap is already corrupt by the time we get here. The crash site is where it surfaces, not where it happens.

2. The loop-back-edge hypothesis is refuted

Compiling with PERRY_GC_MOVING_LOOP_POLLS=0 (so zero js_gc_loop_safepoint polls are emitted) and running with the runtime default (polls on) still gives 5/5 SIGSEGV. The new safepoint is not required. Controls: compile-with-polls + run PERRY_GC_MOVING_LOOP_POLLS=0 → 5/5 clean & byte-exact; compile-and-run with polls off → 5/5 clean.

3. rewrite_raw_addr is exonerated

I restored the pre-#7019 classify()-based body behind an env gate (same binary, same config): still 5/5 SIGSEGV. #7019's only ungated runtime behaviour change is not the cause.

4. What #7019 actually changed here: the nursery trigger, not soundness

The discriminator is effective_next_arena_trigger()'s new min(gc_scavenge_nursery_cap_bytes()) clamp. With PERRY_GC_SCAVENGE_NURSERY_MB=128 the run is clean and still live (35 cycles, 1,026,015 objects copied by the copying minor) — not a vacuous pass. PERRY_GC_SCAVENGE=1 PERRY_GC_SCAVENGE_NURSERY_MB=16 reproduces the crash with the deferral off, so it is the trigger schedule, not the deferral.

5. Minimal repro (20 lines, deterministic)

let churnSink: unknown[] = [];
let churnAcc = 0;
function churn(i: number): void {
  churnSink.push({ i: i });
  if (churnSink.length > 4096) { churnAcc = (churnAcc + churnSink.length) | 0; churnSink = []; }
}
const N = 320000;
for (let i = 0; i < N; i++) { churn(i); }
console.log("churnAcc", churnAcc);

PERRY_GC_HEAP_LIMIT=8 PERRY_GC_INCREMENTAL=0 PERRY_CONSERVATIVE_STACK_SCAN=off PERRY_GC_SCAVENGE_NURSERY_MB=2 → 5/5 SIGSEGV.

No representation-selected local is involved. Required ingredients, each measured by ablation:

• pushing a heap object (push(i) with a number: clean at every cap)
• the array must grow (fixed-capacity sink, no growth: clean at every cap)

6. Hypotheses refuted by measurement (each an env-gated A/B in one binary)

hypothesis	instrument	result
stale write into a deallocated arena block	leak all 8 std::alloc::dealloc(block.data) sites	still 5/5 crash
malloc-tracked object swept while live	leak oldgen.rs process_sweep_header's dealloc	still 5/5 crash
out-of-bounds write past an arena block	every block mmap'd with PROT_NONE guard pages both sides, block flush against the trailing guard	guards never fire; still 5/5 crash
stale reference reading recycled from-space	skip the copying minor's Eden reset_region_to_zero	still 4/5 crash
PERRY_GC_VERIFY_EVACUATION=1 catches it	—	never fires; SIGSEGV, not a verifier panic

⚠️ One trap worth recording: my first guard-page run came back clean, but that was a confound — mmap with a NULL hint lands below HEAP_MIN = 0x200_0000_0000, and js_array_grow silently skips stub installation below that bound. Re-running with a high MAP_FIXED hint (0x5000_0000_0000, same band mimalloc reserves) restored the crash.

7. The necessary condition: the array-growth forwarding stub

js_array_grow installs set_forwarding_address(old_header, new_ptr) — a permanent GC_FLAG_FORWARDED on a live object, outside evacuation. Gating just that one call off, changing nothing else:

binary	baseline	PERRY_GC_NO_GROWTH_STUB=1
minimal repro	139 139 139 139 139	0 0 0 0 0
test_gap_repsel_gc_stress	139 139 139 139 139	0 0 0 0 0, byte-exact vs oracle

And the two collectors disagree about these stubs:

• the non-moving sweep deliberately retains them (gc/types.rs:880, retained_forwarded_stub_objects in the sweep telemetry — measured 24 stubs / 50,048 bytes in the repro);
• the copying minor reports retained_forwarded_stub_objects: 0 (gc/copying.rs:1266) and resets from-space wholesale — gc: default-on evacuating young-gen scavenge (moving minor at precise safepoints) #7019's own comment in gc/mod.rs:256 calls this out as a feature ("the non-moving in-place sweep ... cannot reclaim array-growth stubs").

That is exactly the 12-vs-8 arm split: PERRY_CONSERVATIVE_STACK_SCAN=off is what makes the copying minor eligible, and the copying minor is the one that does not honour the growth-stub contract.

8. Classification

On the evidence: not a missing precise root, and not a collector forwarding bug in rewrite_raw_addr. It is a missing rewrite — some holder of a pre-grow array pointer is not updated by the copying minor, and the retained growth stub was silently covering for it in the non-moving collector, exactly as the conservative stack scan covers missing roots. #7019 removed that safety net by making the moving minor the primary nursery path.

I could not identify which holder before running out of session budget, and PERRY_GC_VERIFY_EVACUATION does not see it. Next step I would take: after the copying minor's rewrite pass, sweep every registered side table and root surface for any address still inside from-space, and report the surface name — the verifier's current coverage demonstrably has a hole where this holder lives.

No fix is proposed here. PERRY_GC_NO_GROWTH_STUB is a bisect instrument, not a candidate fix — it breaks the #233 contract that stale pre-grow references resolve through the stub.

[proggeramlug]

Update: the growth stub is causal (controlled), but all three of its followers audit clean — and my earlier "missing rewrite" classification is not established

Same environment as my previous comment (origin/main @ 775e29193, release, macOS arm64, node 26.5.0). Filed the verifier hole separately as #7035.

1. set_forwarding_address does two things; neither alone reproduces

js_array_grow's stub install both (a) overwrites the first 8 payload bytes — which for an array is exactly ArrayHeader { length: u32, capacity: u32 } — with the new user pointer, and (b) sets GC_FLAG_FORWARDED. Splitting them (PERRY_GC_STUB_MODE):

mode	behaviour	result
0	shipped (payload + flag)	139 ×5
1	no stub at all	0 ×5
2	payload clobber only, no flag	0 ×5
3	flag only, payload intact	0 ×5

So it is not the destroyed length/capacity, and not the flag. It is specifically a stub that can be successfully followed.

2. Causality control — this is not schedule perturbation

Each stub mode changes reachability and therefore the collection schedule (the per-minor copied_objects sequences diverge from minor #6 onward), and this bug is very schedule-sensitive. So "no stub → clean" on its own proves nothing — a perturbation would just move the crash window. Sweeping the nursery cap 1→64 MB, 2 runs per cell:

stub_mode=0: 1=.. 2=XX 3=XX 4=XX 5=XX 6=XX 8=.. 12=.. 16=.. 24=.. 32=.. 48=.. 64=..
stub_mode=1: 1=.. 2=.. 3=.. 4=.. 5=.. 6=.. 8=.. 12=.. 16=.. 24=.. 32=.. 48=.. 64=..
stub_mode=2: 1=.. 2=.. 3=.. 4=.. 5=.. 6=.. 8=.. 12=.. 16=.. 24=.. 32=.. 48=.. 64=..
stub_mode=3: 1=.. 2=.. 3=.. 4=.. 5=.. 6=.. 8=.. 12=.. 16=.. 24=.. 32=.. 48=.. 64=..

Shipped mode fails across a contiguous 5-cap band (10/10). Every split mode is clean at all 13 caps (78 runs). A schedule shift would relocate the band, not erase it. The stub's followability is causal.

3. …but every follower of the chain audits clean

There are exactly three places that follow GC_FLAG_FORWARDED. I instrumented all three on the crashing configuration:

• CopyingNurseryCollector::mark_addr, non-young kinds (Malloc / Longlived / Old — none of which check the flag, unlike move_young): 0 events. The copying minor never marks or scans a forwarded object as a live non-young object. This kills the "stub scanned as an array with a pointer-derived length" theory.
• move_young's forwarding branch: fires, and always resolves — mark_addr(forwarded).unwrap_or(forwarded) never takes the unwrap_or fallback (0 dangling events). Stubs live in NurseryEden, targets in Survivor1 (to-space), and chains occur (stub → stub → target). Stubs are left stale after their target is evacuated, but nothing follows them afterwards.
• clean_arr_ptr's chain walk (the mutator side, issue Array.push from inside an async function silently caps at 16 elements when the array is a function parameter #233): 0 bad follows — every resolved head is a live GC_TYPE_ARRAY in a registered heap region.

Additional refutations this round, each an env-gated A/B in one binary: writing the resolved address back into the stub when its target moves (stub refresh) — still 5/5; suppressing the copying minor's from-space reset for both Eden and the survivor semispace (my earlier test only covered Eden, so it was inconclusive) — still 5/5.

4. Correction to my earlier classification

I previously classified this as a missing rewrite on the reasoning that the stub was covering for an un-rewritten holder of a pre-grow array pointer. That is not established, and the follower audits argue against it: if a stale holder were resolving through the stub, clean_arr_ptr would have to be the one resolving it, and it reports zero bad resolutions.

Flagging this explicitly because it was being read as evidence about root sources: #7022 is currently not evidence for or against a shadow-stack → statepoints migration. I have no established root-source claim either way.

What is solid: the corruption is in the malloc heap (fault is a byte read of a corrupted pointer inside mimalloc's realloc, reached from the GC's own Vec growth); it requires the moving minor (PERRY_CONSERVATIVE_STACK_SCAN=off); it requires a followable array-growth stub; and it survives leaking freed arena blocks, leaking swept malloc-tracked objects, guard pages on every arena block (which never fire), and both from-space resets being suppressed.

5. Where I would look next

The stub is causal but no follower misbehaves, so the effect is likely indirect: following the stub changes which object graph the collector builds, and something downstream of that is wrong. Concretely, I would (a) diff the evacuated-object set and the survivor/old-gen layout between mode 0 and mode 2 for the first divergent minor (#6 — mode 0 copies 17414, mode 2 copies 13762), and (b) add the whole-heap from-space scan proposed in #7035, which is the only instrument that would catch an un-rewritten holder independently of the rewrite pass's own enumeration.

Repro is 8 lines of TypeScript and deterministic at PERRY_GC_SCAVENGE_NURSERY_MB 2–6; it is in my previous comment.

[proggeramlug]

The holder is identified: old-gen arrays whose element slots hold un-rewritten references to evacuated nursery objects

Found with the whole-heap from-space scan proposed in #7035 and implemented in #7041. That instrument is what cracked this: it asks whether any live object outside from-space still contains a word decoding to a from-space address, and it depends on no root enumeration — so unlike PERRY_GC_VERIFY_EVACUATION it can see a holder the rewrite pass never knew about.

On the minimal reproducer (PERRY_GC_HEAP_LIMIT=8 PERRY_GC_INCREMENTAL=0 PERRY_CONSERVATIVE_STACK_SCAN=off PERRY_GC_SCAVENGE_NURSERY_MB=2):

[gc-fromspace-scan clean]     objects=4614  missing_rewrites=0     dangling=0     owners=0
[gc-fromspace-scan OFFENDERS] objects=17868 missing_rewrites=20480 dangling=0     owners=7  | never_dirty=0    lost_dirty=0     dirty_but_missed=20480
[gc-fromspace-scan OFFENDERS] objects=31733 missing_rewrites=35328 dangling=5635  owners=15 | never_dirty=5    lost_dirty=18380 dirty_but_missed=22578
[gc-fromspace-scan OFFENDERS] objects=40877 missing_rewrites=22723 dangling=29958 owners=18 | never_dirty=0    lost_dirty=40239 dirty_but_missed=12442
[gc-fromspace-scan OFFENDERS] objects=54767 missing_rewrites=48792 dangling=22724 owners=24 | never_dirty=0    lost_dirty=52836 dirty_but_missed=18680
...

Every offending owner is an obj_type=1 (GC_TYPE_ARRAY) object in Old, with long runs of consecutive element slots pointing into NurseryEden:

owner=0x…0e9a0 type=1 space=Old +144 nanbox -> 0x…9a740 (NurseryEden) MISSING-REWRITE (target moved) [slot dirty_now=false ever_dirty=true]
owner=0x…0e9a0 type=1 space=Old +152 nanbox -> 0x…9a788 (NurseryEden) MISSING-REWRITE (target moved) [slot dirty_now=false ever_dirty=true]
…

That is churnSink — the old-gen array being pushed into. The defect is in the old→young remembered-set path, not in precise roots, not in the shadow stack, and not in any follower of GC_FLAG_FORWARDED.

The first collection is clean; it starts on the second, which is consistent with the array having reached old-gen by then.

The coverage split says it is a lost edge, not a missing barrier

Using the pre-existing EVER_DIRTY_OLD_PAGES tracking (whose own comment calls this "the decisive split for the missing old→young edge bug"):

• never_dirty is ~0 throughout — so a store path is not skipping the write barrier;
• lost_dirty dominates from the third collection on (18380 → 40239 → 52836 → 63531) — the edge was recorded and was then dropped;
• dirty_but_missed is large on the second collection (20480, with lost_dirty=0) — the page is dirty at scan time yet the slot was still not rewritten, which is what you would expect if the page was dirtied after remembered_dirty_snapshot() was taken for that cycle.

So the two shapes to look at are remembered_set_clear() + restore_surviving_dirty_coverage() at the end of each minor (the lost_dirty population), and edges created during a cycle after the dirty snapshot was taken (the dirty_but_missed population). Promotion into old-gen inside move_young is a candidate for the latter: a promoted object lands in old-gen still referencing objects that stayed young.

Corroboration already on main

gc::tests::copying::large_object_old_born_array_slot_write_keeps_young_child_alive is red on main (775e29193) — verified at pristine HEAD in a clean worktree — and it asserts exactly this invariant. That test failing and this crash are very likely the same defect.

One caveat, stated because I nearly reported it as a result

I also instrumented GC_FLAG_MARKED on the offending owners and got owner_marked=0 everywhere. That is not evidence that the collector never scanned them: during a minor, old-gen parents are not marked even when their slots are scanned through the remembered set. I dropped that metric from #7041 rather than ship a misleading counter.

Status

No fix. The instrument (#7041) lands on its own merit. The classification is now missing rewrite of an old→young edge, directly observed rather than inferred — but note this is a remembered-set defect, so it still says nothing about shadow-stack vs statepoints root sourcing.

[proggeramlug]

Root-caused and fixed in #7050: Arena::alloc(&mut self, ..) ran gc_check_trigger() from inside its own borrow, and a collection allocates into the same arena — install_fresh_block → self.blocks.push(..) frees the buffer the outer frame keeps indexing. 139×20 → 0×20 at the default nursery cap; matrix PASS=302→324 / FAIL=46→24. See the PR for the full A/B, and #7041 for why the from-space scan's lost_dirty classification was noise.