gc: PERRY_GC_TRACE=1 SIGSEGVs under the evacuating arms — the liveness instrument crashes on the corpus file that most needs it

[proggeramlug]

Summary

PERRY_GC_TRACE=1 crashes the program it is supposed to be observing. Under the evacuating arms, test_gap_repsel_scalar_replaced_locals SIGSEGVs with the flag set and passes without it.

This matters more than an ordinary flag bug: PERRY_GC_TRACE=1 is the tool this whole campaign relies on to prove a GC arm was live. PERRY_GC_DIAG under-reports (it only prints on some paths), so GC_TRACE's one-marker-per-completed-cycle output is the primary evidence that a green cell means anything. A green cell from an inert arm is exactly the false confidence that invalidated months of this project's earlier results (#6942, #6946, #6950).

So the instrument crashes on the case that most needs instrumenting.

Reproduction

PERRY_GC_HEAP_LIMIT=8 PERRY_GC_INCREMENTAL=0 PERRY_CONSERVATIVE_STACK_SCAN=off \
PERRY_GC_TRACE=1 ./test_gap_repsel_scalar_replaced_locals

• with PERRY_GC_TRACE=1 → SIGSEGV
• without it → passes, byte-identical to the pinned Node 26.5.0 oracle, with copied_objects in the 261 251 – 379 072 range

Not a regression from the hoist

Confirmed pre-existing: reproduced identically on a rebuilt main without PR #7013, same arms, same failure. Reported during #7013's validation and deliberately not folded into that PR.

Status of this report

Measured by the agent that landed #7013; I have not independently re-verified it. First step for whoever picks this up is to reproduce both arms above before doing anything else.

Why it is plausible

The tracer runs inside a collection, walking structures the collector is mid-way through mutating — during an evacuating cycle, objects are being copied and forwarded while the trace reads them. A tracer that dereferences a forwarded-but-not-yet-rewritten pointer, or reads a header on an object already evacuated, would fault exactly here. That is a hypothesis, not a diagnosis; the stack will say.

Note the interaction with #6998 and #6995: both concern root words that are not what the decoder expects, and is_plausible_heap_addr is the shared predicate. If the tracer classifies raw words the same way, it may share their root cause.

Why it should be fixed rather than worked around

Every liveness claim in this campaign — "the arm moved N objects", "no green cell came from an inert arm" — is downstream of this flag. If it cannot run on the evacuating arms for some corpus files, then for those files we have no liveness evidence at all, and cells we currently call verified are only presumed verified.

[proggeramlug]

Re-tested on main = d4ac65f21 and deliberately NOT closed — same reason as #6982.

This issue's own status line asks whoever picks it up to "reproduce both arms above before doing anything else". Doing that:

PERRY_GC_HEAP_LIMIT=8 PERRY_GC_INCREMENTAL=0 PERRY_CONSERVATIVE_STACK_SCAN=off \
PERRY_GC_TRACE=1 ./test_gap_repsel_scalar_replaced_locals

• with PERRY_GC_TRACE=1: rc=0, 5/5. Adding PERRY_GC_FORCE_EVACUATE=1: rc=0, 5/5.
• without it: rc=0, 2/2.

No SIGSEGV on either arm. But the liveness numbers say the comparison is void:

	copy-minors	copied_objects
this issue's cited range, no trace	—	261 251 – 379 072
d4ac65f21, PERRY_GC_TRACE=1	0	0
d4ac65f21, no trace	0	0

The file performs zero copying minors on this build in either arm. The tracer is documented here as crashing because "it runs inside a collection, walking structures the collector is mid-way through mutating" — with no evacuating collection running, it never gets the chance. Green is unfalsifiable.

Blocked on #7255 (the requires=scavenge arms went inert), same as #6982.

Worth noting the second-order cost, which is this issue's own argument turned on itself: PERRY_GC_TRACE=1 is the instrument every liveness claim in this campaign is downstream of, and right now it reports honestly that there is nothing to observe. That is the correct behaviour and it is also why this issue cannot be retired from a green run.

Part of the sweep in #7262.

[proggeramlug]

Judgeable again, and it does not reproduce

#7255 was blocking this: the sweep that found "0 copying minors even with
PERRY_GC_FORCE_EVACUATE=1" was measuring the default/verify_evac family,
which #7161 took to copy-minor 0/50 corpus-wide. This issue's own arm was
never in that family — it is the matrix's evac_minor cell, and that one is
demonstrably live.

Measured on 61410a222 + #7255's branch, release, macOS arm64, node 26.5.1 (the pin):

Liveness of the arm first, because a green run under an inert arm asserts
nothing. test_gap_repsel_scalar_replaced_locals x evac_minor in the matrix:
cycles=61 evacuated=0 scavenged=1577269. The copying minor runs, and it copies
1.58M objects — in the same order of magnitude as the 261 251–379 072 this issue
cites, on a corpus that has grown since.

The exact repro, 10 runs:

PERRY_GC_HEAP_LIMIT=8 PERRY_GC_INCREMENTAL=0 PERRY_CONSERVATIVE_STACK_SCAN=off \
PERRY_GC_TRACE=1 ./test_gap_repsel_scalar_replaced_locals

	rc	GC cycles	output vs node
runs 1–10, with PERRY_GC_TRACE=1	0	61 each	byte-exact
runs 1–10, control without it	0	—	byte-exact

10/10 clean with the tracer on, 61 completed cycles per run, byte-identical to
the pinned oracle. The instrument does not crash the program it observes on this
file at this commit.

I have not bisected to find what fixed it, and the original report was itself
second-hand ("I have not independently re-verified it"). But the two things that
made this unjudgeable — an inert arm, and no way to tell an inert arm from a
clean one — are both gone: the matrix now fails when an arm satisfies its
requires= on zero cells, so a future green on this cell means the copying minor
ran.

Recommend closing as not-reproducing, with the liveness evidence above as the
reason it is safe to.