[youknowone]

Problem

_collections._deque_iterator (W_DequeIter) and _collections._deque_reverse_iterator
(W_DequeRevIter) are #[pyre_class] wrappers that each hold a traced deque: PyObjectRef
managed child, but they were never wired into build_gc. On the native backends the GC-root
completeness oracle (eval.rs, #[cfg(not(target_arch = "wasm32"))], unconditional) therefore
aborts at GC init:

GC-root registration gap: #[pyre_class] type(s) with managed children were never wired into
build_gc ... Register each in build_gc:
["_collections._deque_iterator", "_collections._deque_reverse_iterator"]

This fires before any user code runs, so every native JIT program panics — even a trivial
while loop. main (014bc0fae6b) is affected.

Fix

Both iterators are .allocate()-immortal: allocate lowers to malloc_typed, and the GC
marker skips malloc_typed objects. So they must be registered on the immortal-root path,
register_pyre_class_offsets, alongside W_Enumerate / W_UnpackIter — the immortal-root walker
force-forwards the deque child on every collection. Re-export the two types from _collections
(they live in private submodules) so build_gc can name them.

Correction (force-pushed): the first revision of this branch used register_pyre_class (the
marker-tid path, like W_Deque). That satisfies the completeness oracle's tid check, but the
marker never scans a malloc_typed object, so the deque child would still be swept while the
iterator is live — a latent use-after-free that only surfaces under a major collection. The
current revision uses register_pyre_class_offsets.

Validation

• Distinguishing test: a module-global deque reachable only through a live iterator, then a
  gc.collect() (major collection). With register_pyre_class_offsets the sum matches CPython;
  the earlier register_pyre_class dropped the deque (swept), so this is the test that separates
  the two paths — a light/minor-GC or churn workload passes either way.
• Full check.py: dynasm 241/241, cranelift 241/241 green. One unrelated pre-existing
  wasm-only failure (selfrec_tail_exception_unwind, tracked separately) passes on both natives
  and is not touched by this change.

Summary by CodeRabbit

• Bug Fixes
  • Improved garbage collection handling for forward and reverse collections.deque iterators.
  • Prevented active deque iterators and their underlying data from being incorrectly removed during garbage collection.

[coderabbitai]

Walkthrough

The change re-exports GC-managed deque iterator wrappers and registers both wrapper types in the JIT garbage-collector type registry.

Changes

Deque iterator GC registration

Layer / File(s)	Summary
Expose and register deque iterators pyre/pyre-interpreter/src/module/_collections/mod.rs, pyre/pyre-jit/src/eval.rs	Re-exports W_DequeIter and W_DequeRevIter, then registers both wrapper types in build_gc() at the end of the existing type-ID chain.

Estimated code review effort: 2 (Simple) | ~10 minutes

Suggested reviewers: lifthrasiir

Poem

I’m a rabbit who hops through the heap,
Guarding deque edges while iterators sleep.
Two wrappers now shine in the GC’s bright light,
Their type IDs stay steady and right.
Hop, hop—no deque gets swept out of sight!

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: registering _collections deque iterators as GC roots in the JIT.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch deque-iterator-gcroot

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🤖 Codex parity review

Static analysis of this diff vs the local RPython/PyPy sources (commit 4bbc502).
Updated: 2026-07-20T10:37:54.400Z

Files in the reviewed diff

pyre/pyre-interpreter/src/module/_collections/mod.rs
pyre/pyre-jit/src/eval.rs

1. Regressions to PyPy parity introduced by this patch

None.

2. Other mismatches introduced by this patch

None.

3. Pre-existing mismatches (already present before this patch)

• pyre/pyre-interpreter/src/module/_collections/mod.rs:24 ↔ pypy/module/_collections/interp_deque.py:48 — Pyre represents deque contents as one backing list; PyPy uses linked fixed-size Block objects. This pre-dates the patch and diverges from the upstream storage shape.

• pyre/pyre-interpreter/src/module/_collections/mod.rs:59 ↔ pypy/module/_collections/interp_deque.py:107 — Pyre uses a wrapping i64 mutation generation, while PyPy invalidates an identity-bearing Lock. After counter wraparound, a stale Pyre iterator can theoretically become valid again; the volatile accesses also do not provide PyPy-equivalent synchronization under free-threading. This pre-dates the patch.

4. Structural adaptations

• pyre/pyre-jit/src/eval.rs:1858 ↔ pypy/module/_collections/interp_deque.py:629 and pyre/pyre-jit/src/eval.rs:1860 ↔ pypy/module/_collections/interp_deque.py:697 — PyPy’s GC traces each iterator’s deque field through its normal W_Root object graph. Because Pyre’s W_DequeIter and W_DequeRevIter are Rust-allocated immortal wrappers, registering their generated pointer offsets is the necessary Rust GC adaptation. It preserves the same reachability relationship.

[youknowone]

Force-pushed a corrected revision (37824cdc73b → 4bbc5027b64).

The first revision registered the two deque iterators via register_pyre_class (marker-tid path). That clears the completeness oracle, but W_DequeIter/W_DequeRevIter are .allocate()-immortal (malloc_typed), and the marker skips malloc_typed objects — so the deque child was never actually forwarded and would be swept out from under a live iterator on a major collection (latent UAF). The oracle only checks that a tid is registered, not that the marker reaches the object, so it passed anyway.

Corrected to the immortal-root path register_pyre_class_offsets, next to W_Enumerate/W_UnpackIter, whose walker force-forwards the child on every collection. Verified with an explicit gc.collect() after building a global iterator over a deque (offsets path preserves it; the marker-tid path dropped it). dynasm 241/241, cranelift 241/241.

Note: PR #643 registers the same deque iterators via register_pyre_class and has the same latent gap; it should move to the offsets path too.

— commented by Claude