gc: perry_ffi::alloc_object + later copying minor SIGSEGVs in scan_slot on a bogus slot (0x9) — documented-FFI-only repro

[proggeramlug]

Found while validating PR #7136's GC-survival test (macOS arm64, deterministic under --test-threads=1, using only documented FFI):

perry_ffi::alloc_object() followed by a later gc_collect_minor() in the same process makes the copying collector walk a bogus slot (0x9) and SIGSEGV in gc::copying::scan_slot.

Why this matters

• Reachable through the documented FFI surface alone — any ext crate that allocates an object and later experiences a copying minor can hit it.
• 0x9 looks like a tag-pattern or uninitialized word being treated as a heap slot — same family as the uninitialized-capacity findings (gc: run the allocation-point GC trigger outside the &mut Arena borrow (#7022) #7050: uninit bytes in unused array capacity decoding as pointers; fix(runtime): zero-fill new Uint8Array(n) — buffer_alloc returns reclaimed dirty memory #6429: new Uint8Array(n) returning uninit memory). The FFI object-alloc path plausibly leaves payload slots unwritten where compiled-TS construction would initialize them, and the copying scanner then dereferences garbage.

Repro shape

let obj = perry_ffi::alloc_object(/* … */);
// … later, same process:
gc_collect_minor();   // SIGSEGV in gc::copying::scan_slot walking slot value 0x9

Deterministic single-threaded. Observed on macOS arm64; not yet reproduced on Linux (untested, not ruled out).

Suggested first checks

1. Does perry_ffi::alloc_object zero/initialize payload slots (or set a layout state that keeps the scanner out of uninitialized ones)? Compare against the compiled-TS allocation path's initialization.
2. Whether layout_note_slot/SIDE_MASK state for FFI-allocated objects matches what heap_payload_slot_selection assumes (cf. fix(gc): keep live array elements traced and initialize unused array capacity #7138's stale-POINTER_FREE fix — same selection machinery).
3. A subject-live regression test needs a pristine process — in-suite, conservative stack leftovers pin the object and mask the path (this is how fix(lru-cache): faithful JS-value keys/values, GC rooting, TTL + updateAgeOnGet #7136's test had to be structured).

[proggeramlug]

Narrowing data from PR #7136's round-2 validation (macOS arm64):

The trigger is narrower than "FFI object allocation" — it is the ordinary-prototype path specifically:

construction in the test process	flake rate	deterministic repro
no JS objects	0/12	—
js_object_alloc + js_object_set_field_by_name	1/12 (lands in unrelated tests, e.g. string::compare dereferencing string content as a pointer)	SIGSEGV in gc::copying::scan_slot under --test-threads=1
alloc_null_proto_object + same field writes	0/40 parallel, 0/10 single-threaded	none

Only own properties are read in these tests, so the prototype is immaterial to semantics — the null-proto variant is behaviorally identical and clean. This points at the ordinary-prototype object's initial layout/side-table state (what js_object_alloc records vs what heap_payload_slot_selection/scan_slot later assumes about the proto slot or early field slots), rather than field writes as such.

PR #7136's test files now use null-proto as a documented workaround (commit c1a0852b4) — explicitly marked as a runtime-bug workaround, not a style choice. When this issue is fixed, those tests should be flipped back to js_object_alloc as the regression check.