pola-rs/polars · error

internal error: entered unreachable code

Error message

internal error: entered unreachable code

What it means

`OffsetsBuffer::offset_and_length_iter` walks the offsets buffer with `.windows(2)` and destructures each window with `let [l, r] = x else { unreachable!() }`. Since `windows(2)` always yields length-2 slices, the `unreachable!()` can only fire if the internal iterator contract is violated (or a buffer shorter than 2 elements is iterated in a way that surfaces a 1-element window, which should not happen). This is a defensive internal-invariant assertion, not a validated error path.

Solutions

  1. Guard the input: check `offsets.len() >= 2` before calling offset_and_length_iter and handle empty/single-element buffers explicitly.
  2. Update polars/polars-arrow to the latest patched version; if reproducible, file an issue with the offsets buffer contents.
  3. Avoid patching internals; use the public `offsets().windows(2)` yourself with safe destructuring.

Example fix

// before
for (start, len) in offsets.offset_and_length_iter() { ... }
// after
let slice = offsets.as_slice();
if slice.len() < 2 {
    return Ok(()); // nothing to iterate
}
for (start, len) in offsets.offset_and_length_iter() { ... }
Defensive patterns

Strategy: validation

Validate before calling

if offsets.as_slice().len() < 2 {
    // no (offset, len) pairs exist; skip iteration
    return;
}

Type guard

fn has_offset_pairs(offsets: &[impl Offset]) -> bool { offsets.len() >= 2 }

Prevention

When it happens

Trigger: Iterating `(offset, len)` pairs over an offsets buffer whose underlying slice has fewer than 2 elements — in that case the windows iterator is simply empty and the panic should never occur; it fires only if the windows API contract is broken or the code is refactored to produce different-sized windows. Practically: a bug/regression in the crate, not user input.

Common situations: Debugging polars-arrow internals; using a patched or nightly-modified build where `windows` semantics or the offset buffer layout changed; hitting a genuine crate bug while converting offset buffers to (start, length) pair iterators in list/array processing.

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 pola-rs/polars@fe841f959e (2026-09-18). Data as JSON: /api/errors/9231d3957c607894. Report an issue: GitHub.

Appendix: source

Thrown at crates/polars-arrow/src/offset.rs:529

    ///
    /// # Safety
    /// The caller must ensure `offset + length <= self.len()`
    #[inline]
    pub unsafe fn slice_unchecked(&mut self, offset: usize, length: usize) {
        self.0.slice_in_place_unchecked(offset..offset + length);
    }

    /// Returns an iterator with the lengths of the offsets
    #[inline]
    pub fn lengths(&self) -> impl ExactSizeIterator<Item = usize> + '_ {
        self.0.windows(2).map(|w| (w[1] - w[0]).to_usize())
    }

    /// Returns `(offset, len)` pairs.
    #[inline]
    pub fn offset_and_length_iter(&self) -> impl ExactSizeIterator<Item = (usize, usize)> + '_ {
        self.windows(2).map(|x| {
            let [l, r] = x else { unreachable!() };
            let l = l.to_usize();
            let r = r.to_usize();
            (l, r - l)
        })
    }

    /// Offset and length of the primitive (leaf) array for a double+ nested list for every outer
    /// row.
    pub fn leaf_ranges_iter(
        offsets: &[Self],
    ) -> impl Iterator<Item = core::ops::Range<usize>> + '_ {
        let others = &offsets[1..];

        offsets[0].windows(2).map(move |x| {
            let [l, r] = x else { unreachable!() };
            let mut l = l.to_usize();
            let mut r = r.to_usize();

View on GitHub (pinned to fe841f959e)