Not introduced by anything in flight — verified against a pristine build of origin/main @ e279b2d54 before filing.
Reproduce
cargo build --release -p perry -p perry-runtime -p perry-stdlib \
-p perry-runtime-static -p perry-stdlib-static
cargo test --release -p perry-runtime --lib -- \
--exact gc::tests::copying::large_object_old_born_array_slot_write_keeps_young_child_alive
thread '…large_object_old_born_array_slot_write_keeps_young_child_alive' panicked at
crates/perry-runtime/src/gc/tests/copying.rs:1313:5:
assertion `left == right` failed
left: 4249
right: 1
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 1524 filtered out
Line 1313 is
assert_eq!(trace.copying_nursery.copied_objects, 1);
The test builds one large old-born array with a single young child, writes the child into slot 0, and asserts the copying minor relocates exactly that one young object. It relocates 4 249.
It is the environment, not the change under test
I hit it while validating #7024 and did the control before concluding anything: the failure is byte-identical on the pristine e279b2d54 tree (same panic site, same left: 4249), so it is not caused by the deferral change. It also reproduces with --exact in a fresh process, so it is not cross-test state either — 4 249 live young objects are simply present in the nursery at the point the test forces its minor.
That points at runtime startup allocations differing between this host and the CI runner. cargo-test on main is red for an unrelated reason (direct_eval_non_definable_global_var_throws, a crates/perry/tests case), and this test is not among the reported failures there, so it evidently passes on ubuntu-latest.
Why it matters
The assertion is an exact equality against a whole-process quantity. Whatever makes 4 249 young objects live at that point on macOS will make the number different again on the next platform or the next startup change, and the test says nothing about the property it is trying to pin — that the old-to-young edge kept this child alive and rewrote this slot, which the surrounding assertions already check.
Two candidate fixes, in preference order:
- Assert the child specifically: the test already computes
rewritten and asserts it is a nursery pointer distinct from child. Add that the child's forwarded copy is among the copied set, and drop the exact count — or assert copied_objects >= 1.
- Give the test a controlled nursery (the
CopyingNurseryTestGuard it already uses) that starts from a known-empty young generation, so the exact count is meaningful.
Environment: macOS 15 (Darwin 25.5.0), arm64, release profile, cargo test --release -p perry-runtime --lib.
Related: #6981, #7019.
Not introduced by anything in flight — verified against a pristine build of
origin/main@e279b2d54before filing.Reproduce
Line 1313 is
The test builds one large old-born array with a single young child, writes the child into slot 0, and asserts the copying minor relocates exactly that one young object. It relocates 4 249.
It is the environment, not the change under test
I hit it while validating #7024 and did the control before concluding anything: the failure is byte-identical on the pristine
e279b2d54tree (same panic site, sameleft: 4249), so it is not caused by the deferral change. It also reproduces with--exactin a fresh process, so it is not cross-test state either — 4 249 live young objects are simply present in the nursery at the point the test forces its minor.That points at runtime startup allocations differing between this host and the CI runner.
cargo-testonmainis red for an unrelated reason (direct_eval_non_definable_global_var_throws, acrates/perry/testscase), and this test is not among the reported failures there, so it evidently passes onubuntu-latest.Why it matters
The assertion is an exact equality against a whole-process quantity. Whatever makes 4 249 young objects live at that point on macOS will make the number different again on the next platform or the next startup change, and the test says nothing about the property it is trying to pin — that the old-to-young edge kept this child alive and rewrote this slot, which the surrounding assertions already check.
Two candidate fixes, in preference order:
rewrittenand asserts it is a nursery pointer distinct fromchild. Add that the child's forwarded copy is among the copied set, and drop the exact count — or assertcopied_objects >= 1.CopyingNurseryTestGuardit already uses) that starts from a known-empty young generation, so the exact count is meaningful.Environment: macOS 15 (Darwin 25.5.0), arm64, release profile,
cargo test --release -p perry-runtime --lib.Related: #6981, #7019.