pydantic/monty · error

entry just allocated

Error message

entry just allocated

What it means

This is a test-only panic from `expect("entry just allocated")` in the cycle-collection unit-test helper `alloc_self_cycle` (crates/monty/src/heap/mod.rs:2326). After `heap.allocate(...)` returns an id, the helper scans `heap.entries` for the matching entry; the expect fires only if that freshly allocated id is not found. It is an internal invariant assertion, not a runtime error surfaced to library users.

Source

Thrown at crates/monty/src/heap/mod.rs:2326

    };

    /// Returns whether a heap entry is still allocated at `id`.
    fn is_alive(heap: &Heap, id: HeapId) -> bool {
        heap.entries.iter().any(|(other, _)| other == id)
    }

    /// Allocates a self-referencing one-element list and returns its id.
    ///
    /// The list's items become `[Value::Ref(id)]` and its refcount is bumped
    /// to 2 to reflect both the caller's ref and the new self-reference.
    fn alloc_self_cycle(heap: &Heap) -> HeapId {
        let id = heap.allocate(HeapData::List(List::new(vec![])));
        let entry = heap
            .entries
            .iter()
            .find(|(other, _)| *other == id)
            .map(|(_, e)| e)
            .expect("entry just allocated");
        // SAFETY: no other borrow into this entry's data exists during the test.
        let data = unsafe { &mut *entry.data.0.get() };
        match data {
            HeapData::List(list) => {
                list.set_contains_refs();
                list.as_vec_mut().push(Value::Ref(id));
            }
            _ => unreachable!(),
        }
        // The new self-pointer counts as one more reference into the entry.
        heap.inc_ref(id);
        id
    }

    /// Allocates a two-element cycle where one direction has multiplicity 3:
    /// `P → [A, A, A]` and `A → [P]`. Returns `(p_id, a_id)`.
    ///
    /// Final refcounts: `P.rc = 2` (alloc + one edge from A), `A.rc = 4`

View on GitHub (pinned to adc986b362)

Solutions

  1. Verify `Heap::allocate` returned a real id and the tracker did not reject/abort the allocation; print `id` before the find.
  2. Check that the `HeapEntriesIter` used by `heap.entries.iter()` yields initialized, live slots (compare with `StableHeap::len`).
  3. Ensure no `dec_ref`/free of the entry happened between `allocate` and the lookup in the test helper.
  4. If the panic appears after refactoring heap internals, restore the invariant that allocate appends/reuses a slot before returning, or use `heap.entries.get(id)`/`entry(id)` instead of a linear find.

Example fix

// before
let entry = heap.entries.iter().find(|(other, _)| *other == id)
    .map(|(_, e)| e).expect("entry just allocated");
// after
let entry = heap.entries.entry(id).expect("entry just allocated").into_inner();
Defensive patterns

Strategy: validation

Validate before calling

assert!(heap.entries.iter().any(|(other, _)| other == id), "id {id:?} not live before mutation");

Type guard

fn is_alive(heap: &Heap, id: HeapId) -> bool {
    heap.entries.iter().any(|(other, _)| other == id)
}

Prevention

When it happens

Trigger: Running the heap unit tests where `alloc_self_cycle` iterates `heap.entries.iter().find(|(other, _)| *other == id)` and the id returned by `Heap::allocate` is not present among the iterated entries — e.g. if `HeapEntriesIter` skips live slots, if allocate returned a freed/reused id, or if entries storage was mutated between allocate and the find.

Common situations: Developers modifying `StableHeap` iteration (`HeapEntriesIter::new`) or `Heap::allocate`/free-list reuse in crates/monty/src/heap/, breaking the guarantee that a just-allocated id is immediately visible to iteration; also seen when a test allocator change (ResourceTracker limits, page allocation) silently fails to insert the entry.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors


AI-assisted analysis of pydantic/monty@adc986b362 (2026-09-13). Data as JSON: /api/errors/94381166e334ff9e. Report an issue: GitHub.