Repository navigation
perry-ext-net: gc_mutable_scanner_rewrites_listener_roots fails on main #8636
Description
perry-ext-net's gc_mutable_scanner_rewrites_listener_roots fails on clean main (reproduced at ad25921e7).
test tests::gc_mutable_scanner_rewrites_listener_roots ... FAILED
panicked at crates/perry-ext-net/src/tests.rs:59:5
test result: FAILED. 27 passed; 1 failed
Line 59 is:
fn assert_rewritten(before: i64, after: i64) {
assert_ne!(after, before);
assert!(perry_runtime::arena::pointer_in_nursery(after as usize));
}So the test requires a GC root to have moved across a collection, and it is the assert_ne! that fires — the object did not move. That is the "fixture allocated but nothing was evacuated" shape: the test cannot distinguish "the mutable scanner failed to rewrite the root" from "no evacuating collection ran at all", and right now it is failing for one of those two reasons.
Two possibilities worth separating:
- the scanner genuinely stopped rewriting listener roots — a real GC bug;
- the fixture no longer drives an evacuating minor in this environment, so
after == beforebecause nothing moved.
The second is the more likely reading given the test is asserting movement rather than correctness of a value, and it is the same class as other fixtures here that allocate without churning. Either way the test should assert its subject ran (e.g. that a copying minor actually occurred / copied_objects > 0) before asserting the address changed — otherwise a green run does not mean the scanner works, and a red one does not mean it is broken.
Reproduce:
RUST_TEST_THREADS=1 cargo test --profile perry-dev -p perry-ext-net --libFound while auditing #8632; confirmed not caused by it (identical failure on clean main).
Activity
proggeramlug commentedon Aug 23, 2026
Sharper diagnosis — it is not random flakiness, it deterministically depends on the collector mode:
Reproduced on
perry-ext-net@e727da9e4+ #8637, single-threaded, back to back.That matches the assertion exactly:
assert_rewrittenrequiresassert_ne!(after, before)— the root must have moved. With no evacuating collection the object stays put,after == before, and it fails. So the test's precondition is "an evacuating minor ran", and it currently just assumes that rather than arranging or asserting it.Corroboration from outside: #8637's own validation line reads "perry-ext-net: 28 passed with forced evacuation" — the author ran it the way it needs to be run, which is why they saw green where a default
cargo testsees red.Two ways to fix, either is fine:
PERRY_GC_FORCE_EVACUATE(or otherwise drive an evacuating minor) itself, so it is self-contained; orcopied_objects > 0) before asserting the address changed, so a run that never evacuated skips rather than failing.(2) is the more honest shape: as written, a green run does not prove the mutable scanner rewrites roots — it only proves an evacuation happened to occur. That is the same "assert the subject ran" gap as the #8625 fixture.
proggeramlug commentedon Aug 24, 2026
Fixed by merged PR #8712 (superseding #8711).