Repository navigation
release blocker: stable packed loop reads stale forwarded array after cross-call growth #9117
Description
Release blocker
The full release CI run for v0.5.1519 fails deterministically in:
cargo-test-perry (8/8)issue_5139_object_arraylike_method_dispatch::any_typed_real_arrays_keep_array_mutator_semantics
Observed output:
grow: 1000 1000 165171
Expected sum: 499500. Sampled array values (0, 1, 2, 99, 500, 999) are correct, so storage is intact and the optimized reduction is wrong.
Reproduction
RUST_TEST_THREADS=1 cargo test -p perry \
--test issue_5139_object_arraylike_method_dispatch \
any_typed_real_arrays_keep_array_mutator_semantics -- --exact --nocaptureReproduced independently on perrymaster.skelpo.net at release SHA 259cf8b68dc1303cc4119595f96d458a52af8c4e.
Bisect
Automated exact compiler/runtime bisect:
- good:
da0eefbf99a80da0b00020c0ae1c4bb88a1147ca - first bad:
57926713b078df354d7cf76ff11eaa18d5de76fb(perf(codegen): reduce accumulators earn the packed fast clone's numeric proof — s += arr[i] at node parity (was 5.3×) #9060)
The array is grown across a call boundary and the caller retains a forwarding stub. js_packed_arraylike_loop_guard follows that stub and validates the live target, but the ordinary-local stable-packed path discards the live address and reloads/de-tags the stale local for direct fast-clone reads. #9060 makes that clone reachable for the reduction by classifying js_shadow_slot_set as call-safe.
Required fix
Use js_packed_arraylike_loop_guard_live for ordinary-local admission as well as captured receivers, and feed its returned live receiver address to the fast clone. Retain the generic slow clone on a zero result. Update IR assertions to expect the stronger live guard.
Before merging/releasing, verify:
- the exact issue_5139 test above;
- all three issue_8690 versioned-loop tests, including three live-guard calls in the read-only IR fixture;
- issue_8655 and issue_8773 packed-loop IR/runtime coverage;
- quick pre-tag checks.
Activity
fix(codegen): use live receiver in stable packed loops (#9117)
proggeramlug commentedon Aug 31, 2026
Stale — closing.
Verified green on release candidate
01463b81610f089cc566011d16ea5e5b08ec70a8(run 33346563641): all 8cargo-test-perryshards pass andcompiler-output-regressionpasses. No fix for this issue appears in main's history, so it was resolved incidentally by other merges rather than by a targeted change.The subject was confirmed live, not skipped — e.g. #9117's
any_typed_real_arrays_keep_array_mutator_semanticsappears 3× in shard 2's log (shard assignment moves between runs) and that shard passed.Reopen if it resurfaces on a later candidate.
proggeramlug commentedon Aug 31, 2026
Reopening — I closed this prematurely and the evidence for closing was too weak.
It is failing again on release candidate
83754818ea(full-tier run 33372993990,cargo-test-perry (4/8)), with output byte-identical to the original report:Same wrong sum — 165171 rather than 499500.
Why the closure was wrong
I closed this because all 8
cargo-test-perryshards were green on the previous candidate01463b8161, and I confirmed the test genuinely ran and passed there (shard 2 printedtest any_typed_real_arrays_keep_array_mutator_semantics ... ok— not merely present in the log, actuallyok).That observation was correct but the inference was not. This issue's own diagnosis says the sampled array values are correct and "the optimized reduction is wrong" — an optimizer bug. Its visibility depends on codegen decisions that shift with unrelated merges, so it can pass on one candidate and fail on the next with no change to the code under test. For this class, one green run is not evidence of a fix; only a root-caused change is.
Nothing between
01463b8161and83754818eatargeted this bug, so it was masked rather than fixed.Impact
cargo-test-perryis infull-suite-gate'sneeds, so this blocks the v0.5.1519 release.Reproduction
RUST_TEST_THREADS=1 cargo test -p perry \ --test issue_5139_object_arraylike_method_dispatch \ any_typed_real_arrays_keep_array_mutator_semantics -- --exact --nocaptureNote when reproducing: because visibility is optimization-dependent, a local pass does not clear it. Confirm against the candidate SHA and the same profile CI uses.
proggeramlug commentedon Aug 31, 2026
Additional data for whoever picks this up.
It is not intermittent in the ordinary sense — it is optimization-state dependent. Observed on release candidates:
01463b8161... ok(shard 2)83754818eaNothing between those two commits targeted this defect, and the crate under test was unchanged. So the difference is which optimizer decisions the surrounding tree produces, exactly as the original diagnosis implies ("sampled array values are correct … the optimized reduction is wrong").
Practical consequence for anyone verifying a fix: a green run proves nothing on its own here. A local pass, or a pass on one candidate, is consistent with the bug being present and merely masked. Only a root-caused change should close this — I closed it on a single green run and had to reopen it.
Note the shard number moves between runs (2 → 4), so grep the whole
cargo-test-perrymatrix for the test name rather than a fixed shard.fix(codegen): use live receiver in stable packed loops (PerryTS#9117)
fix(codegen): use live receiver in stable packed loops (#9117) (#9270)