gc: test_gap_repsel_gc_stress SIGSEGVs intermittently in a copying minor with the conservative stack scan ON (PERRY_GC_INCREMENTAL=0)

[proggeramlug]

Separate from the precise-roots family: this one crashes with the conservative native-stack scan ON, so it is not an unrooted-temporary bug.

Repro

Release build, macOS arm64, origin/main + #6977 (the fix in #6977 is not on this path — PERRY_GC_INCREMENTAL=0 bypasses the budgeted stepper entirely, so this reproduces on plain main given the same escape hatch).

$ perry test-files/test_gap_repsel_gc_stress.ts -o gc_stress
$ for i in 1 2; do PERRY_GC_HEAP_LIMIT=8 PERRY_GC_INCREMENTAL=0 ./gc_stress >/dev/null; echo "rc=$?"; done
rc=139
rc=139

Intermittent — roughly 2 of 3 runs. With PERRY_GC_TRACE=1 PERRY_GC_DIAG=1 added:

run1 rc=139  output mismatch
run2 rc=0    output matches the Node oracle
run3 rc=139  output mismatch

PERRY_GC_INCREMENTAL=0 is a documented escape hatch, and it is what makes gc_check_trigger take the #5476 direct-collection arm instead of handing the trigger to the budgeted stepper. On this path the collection is a real copying minor: the passing runs report [gc-copy-minor] ran copied_objects=... in the thousands.

Why it is a distinct defect

Every other corpus file passes on this exact configuration while relocating thousands of objects (see the table in the precise-roots issue — 19/20 OK in the conservative-scan column). test_gap_repsel_gc_stress is the one corpus member deliberately built to be GC-live, i.e. the one that drives the collector hardest, and it is the only one that crashes with conservative pinning still in force. So this is not "precise roots lost a value"; something in the copying minor itself is unsound under sustained churn.

The nondeterminism (same binary, same env, different outcome per run) points at a timing/ordering window rather than a fixed miscompile.

Why nobody saw it

test_gap_repsel_gc_stress is green in the matrix's shipped-configuration arms because in the shipped configuration it never takes this path: with incremental mode on, the budgeted cycle handles the trigger. #6950 documents that the shipped automatic paths never produce a copying minor at all. So the only way to reach this crash is the escape hatch, and nothing was running the escape hatch against the corpus until #6977 added the arm.

Suggested next step

Bisect against the copying-minor phases with PERRY_GC_VERIFY_EVACUATION=1 and PERRY_GC_VERIFY_MARK=1, and check whether the crash survives PERRY_GC_FORCE_EVACUATE=0 — i.e. whether it needs actual relocation or only the copying-minor code path. A core dump / lldb backtrace on a repro run should localise it quickly given how reliably it fires.

Related: #6950, #6977, #6892 (minor-sweep finalization), #6910.

[proggeramlug]

Evidence from the #6981 investigation — and an explicit warning against over-reading it

While fixing #6981 (PR #6990), five of that issue's fourteen red files turned out to be GC-internal crashes rather than the typed-array-constructor bug: repsel_canonical_i32, repsel_ptr_shape_locals, repsel_proven_this_frozen, ta_param_numeric_read, typedarray_param_read.

The concrete part

In two crashes examined in detail (an ad-hoc probe and typedarray_param_read), the faulting instruction was identical:

ldrb w8, [x21, #-0x8]!      ; faulting addresses 0x300000020b, 0x15

That is a GC-header obj_type read at addr-8 — the collector validating a pointer that should never have reached it. So the defect is not in the read; it is in whatever installs that pointer. typedarray_param_read was bisected to a single line, console.log("u8", xorU8(u8, 8)), whose init sequence and param-read shape each pass in isolation.

The part that is NOT established — please do not inherit this as fact

An earlier summary (mine) described these as "frame-for-frame identical stacks — one shared collector defect, not five bugs." That overstates the evidence:

• The stacks were matched by offset-into-unnamed-symbol in a stripped binary (+46704, +156, +72, +60, +14656, +8048), not by symbol name. Strong pattern-matching, not proof of a shared path.
• Only two stacks were compared. The other three crashers were grouped by crash class, not by stack.

So "5 sites, 1 defect" is a hypothesis with n=2, and any claim that it subsumes this issue is downstream of that hypothesis.

Cheapest next step

Rebuild with symbols and re-collect stacks for all five. That settles in one build whether this is one defect or several, and it should come before any fix attempt — scoping a fix around a shared root cause that turns out to be three separate bugs would waste the work.

Reproduce on the evacuating precise-roots arm, and confirm relocation actually happened ([gc-copy-minor] copied_objects=N, N > 0):

PERRY_GC_HEAP_LIMIT=8 PERRY_GC_INCREMENTAL=0 PERRY_CONSERVATIVE_STACK_SCAN=off

A green run where nothing moved proves nothing — the failure mode #6942/#6946/#6950 documented and #6977 removed.

Related: #6981, #6990, #6968, #6977.

[proggeramlug]

Settled: symbolized stacks for all five, and the premise does not survive them

You were right to insist on this before any fix. No symbols build was needed — post_link.rs::strip_final_binary skips strip when PERRY_DEBUG_SYMBOLS=1 is set, so the (already unstripped) runtime symbols survive into the linked test binary and the macOS crash report symbolizes directly.

All five reproduce from aa1c15028 with copied_objects matching #6981's table exactly (4 579 / 4 640 / 4 614 / 5 948 / 5 965), and without auto-optimize.

The stacks

repsel_canonical_i32 / repsel_ptr_shape_locals   SIGBUS  0x18400001fc
  0  js_array_length + 488
  1  js_object_set_field_by_name + 5964
  2  populate_global_this_builtins + 45592
  3  js_get_global_this + 156
  4  js_get_global_this_builtin_value + 72

repsel_proven_this_frozen                        SIGSEGV 0x434c4f5300000010
  0  descriptor_state::get_accessor_descriptor + 136
  1  js_object_set_field_by_name + 5728
  2  populate_global_this_builtins + 45592

ta_param_numeric_read                            SIGSEGV 0x004e614e00000008
  0  descriptor_state::set_builtin_property_attrs + 456
  1  populate_global_this_builtins + 46820

typedarray_param_read                            SIGBUS  0x300000020b
  0  get_field_by_name_tail::get_field_by_name_object_tail + 10444
  1  js_object_get_field_by_name + 8048
  2  js_get_global_this_builtin_value + 396

Two corrections to the issue

1. These are not GC-internal crashes. There is not one GC frame in any of the five — no mark, trace, copying or evacuate. The ldrb w8, [x21, #-0x8]! is js_array_length reading an array header at arr-8: an ordinary mutator read. The collector is not the code validating a bad pointer; it is the code that moved the object out from under the mutator. (is_plausible_heap_addr would have rejected both quoted addresses anyway — on macOS HEAP_MIN is 2 TB and both are below it — which is a hint the faulting read was never a validation path.)

2. The real faulting addresses carry ASCII. 0x434c4f53 = "CLOS", 0x004e614e = "NaN" — relocated string payload being read where a pointer/descriptor was expected. That is the signature of a stale from-space pointer whose bytes have been recycled, not of a small integer or tag remnant.

One defect or several?

The five crashes shared one blocking defect, and it was masking at least two more. All five fault downstream of the same js_get_global_this_builtin_value -> populate_global_this_builtins spine, at four different sites — the site varies only with where the recycled bytes landed. So "one shared defect" was directionally right, but it is one shared first hurdle, not the whole story.

Root cause: js_get_global_this registers two root slots for the singleton so an evacuating collector rewrites them, then passes the raw pre-GC pointer by value into populate_global_this_builtins, which allocates on nearly every step. Fixed in #6994 by rooting it in a RuntimeHandleScope and re-reading through the handle.

After that fix, crashes on the arm go 6 -> 2, repsel_canonical_i32 flips to byte-identical-to-Node, and two independent defects become observable: #6991 (compiled constructor receiver stale — the #6983 ctor-receiver class) and #6992 (proven-this method value lost).

Also worth knowing: the per-PR matrix arms cannot reproduce this class at all. On the unfixed binaries, default, verify_evac, cons_scan_off and shipped_default are all green; the evacuating base needs PERRY_GC_INCREMENTAL=0 and PERRY_CONSERVATIVE_STACK_SCAN=off together, which only appears in --arms all (push-only). Filed as #6993.