Repository navigation
gc: test_gap_repsel_scalar_replaced_locals SIGSEGVs intermittently (11/20) under #7019's moving minor — and it is not #7018 #7023
Description
Split out of the post-#7019 matrix re-measurement. New red, attributed to #7019 by A/B on the same source and compiler. Sibling of #7022 (gc_stress), filed separately because the failure is intermittent here and deterministic there, and because it also reaches the default arm.
Symptom
test_gap_repsel_scalar_replaced_locals SIGSEGVs (exit 139) in 10 of 20 arms of scripts/gc_repsel_matrix.sh --arms all --pressure 8: default, evac_minor, force_evac, cons_scan_off, cons_scan_off_force, loop_polls, rep_i32_off, rep_ptr_numarray_off, rep_spec_abi_off, rep_int_valued_off.
It is the file added by #7007/#6968 for escape-analysis-scalarised object/array locals, whose per-field allocas belong to no HIR local — exactly the values a precise-roots collection cannot see unless the shadow-slot pass was taught about them.
It is intermittent, and the rate is config-dependent
Measured with PERRY_GC_HEAP_LIMIT=8 PERRY_GC_INCREMENTAL=0 PERRY_CONSERVATIVE_STACK_SCAN=off, five consecutive runs per binary, on the same host:
| binary (independent compiles of the same source) | exit codes |
|---|---|
| compile A | 139 139 0 0 139 |
| compile B | 139 139 139 0 139 |
compile B, default arm config (PERRY_GC_HEAP_LIMIT=8 only) |
0 0 0 139 0 |
So do not read a single green run as a fix. On a second host (64 GB RAM, hence a larger derived heap budget) it did not reproduce in 15 runs across three configs at all — the derived budget_scaled thresholds move with device RAM, so the crash rate is machine-dependent.
Attribution — measured
Same source, same compiler, A/B through #7019's kill switch with PERRY_GC_MOVING_LOOP_POLLS=0 at both compile and run time, N=20, evacuating config:
| build | SIGSEGV | clean |
|---|---|---|
| default (#7019 on) | 11/20 | 9 |
PERRY_GC_MOVING_LOOP_POLLS=0 (#7019 off) |
0/20 | 20 |
It is not #7018
#7018 reports that PERRY_GC_TRACE=1 SIGSEGVs on this same file under the evacuating arms, i.e. the instrument crashing. That is a different defect: every measurement above ran with no PERRY_GC_TRACE and no PERRY_GC_DIAG and still faults. The instrument is not required to reproduce it. (#7018 remains valid on its own terms and should be fixed separately — while it stands, the liveness instrument is unusable on the one row that most needs it.)
Note for whoever triages the matrix table
Because the rate is well below 100 %, the matrix's per-cell arm assignment for this row is not stable run-to-run: an arm that passes in one full run may fail in the next. Treat "which 10 arms" as indicative and the crash itself as the finding.
Environment: origin/main @ 4340bffc9, release build, macOS arm64, node 26.5.0 pinned.
Related: #7019, #7022, #7018, #6968/#7007 (the fix this file gates), #6981.
Activity
proggeramlug commentedon Jul 30, 2026
Same defect as #7022 — fixed by #7050.
Arena::alloc(&mut self, ..)calledgc_check_trigger()from inside its own borrow, and a collection allocates into the same arena (promotion / C4b evacuation viaarena_alloc_gc_old, an evacuating minor filling a survivor semispace), reachinginstall_fresh_block→self.blocks.push(..)underneath it. That explains the intermittency here as against #7022's determinism: the corruption only bites when the re-entrant push actually reallocates theblocksVec, which depends on where the arena happens to be in its block ladder.Measured after the fix,
scripts/gc_repsel_matrix.sh --arms all --pressure 8:with liveness intact —
evac_minor/force_evac/force_verifyreportcopy-minor 21/22, so the green is not inertness.