tracel-ai/burn · error

read_indices: i64 index {v} out of isize range

Error message

read_indices: i64 index {v} out of isize range

What it means

burn-flex's read_indices converts an index tensor to isize values for addressing. When the index tensor's dtype is I64 and a value cannot be represented as isize (only possible on 32-bit targets where isize is i32), the library panics rather than silently truncating or wrapping an index that would address the wrong element. It is a guard against silent integer-truncation bugs in index conversion.

Source

Thrown at crates/burn-flex/src/ops/gather_scatter.rs:68

/// ([`gather_f32`], [`select_f32`], ...) already share this helper without a
/// check, and asymmetry between the int and float paths was what surfaced
/// the bug.
fn read_indices(tensor: &FlexTensor) -> Cow<'_, [isize]> {
    match tensor.dtype() {
        #[cfg(target_pointer_width = "64")]
        DType::I64 => {
            const { assert!(size_of::<i64>() == size_of::<isize>()) };
            let data = tensor.storage::<i64>();
            Cow::Borrowed(bytemuck::cast_slice(data))
        }
        #[cfg(target_pointer_width = "32")]
        DType::I64 => Cow::Owned(
            tensor
                .storage::<i64>()
                .iter()
                .map(|&v| {
                    isize::try_from(v).unwrap_or_else(|_| {
                        panic!("read_indices: i64 index {v} out of isize range")
                    })
                })
                .collect(),
        ),
        #[cfg(target_pointer_width = "64")]
        DType::I32 => Cow::Owned(
            tensor
                .storage::<i32>()
                .iter()
                .map(|&v| v as isize)
                .collect(),
        ),
        #[cfg(target_pointer_width = "32")]
        DType::I32 => {
            const { assert!(size_of::<i32>() == size_of::<isize>()) };
            let data = tensor.storage::<i32>();
            Cow::Borrowed(bytemuck::cast_slice(data))
        }

View on GitHub (pinned to d16f7ba2ed)

Solutions

1. Run on a 64-bit target where isize == i64 and every i64 index is representable
2. Clamp or validate index tensor values to the valid element range before calling gather/scatter ops
3. Regenerate the indices tensor; garbage values usually indicate a bug upstream (wrong shape, wrong broadcasting)
4. If indices are legitimately huge, the index tensor is semantically wrong — fix the producer, not the consumer

Example fix

// before: indices computed by unchecked arithmetic
let idx = (positions * stride).int();
let out = tensor.gather(0, idx);
// after: clamp to valid range for the dimension
let idx = (positions * stride).clamp(min, dim_size - 1).int();
let out = tensor.gather(0, idx);

// before calling gather/scatter with an i64 indices tensor
let max_idx = indices.max_val::<i64>();
let min_idx = indices.min_val::<i64>();
assert!(min_idx >= i64::from(isize::MIN) && max_idx <= i64::from(isize::MAX));
assert!(max_idx < dim_size as i64);

fn fits_isize_i64(v: i64) -> bool { isize::try_from(v).is_ok() }
// for the whole tensor, check min/max first

When it happens

Trigger: Calling gather, scatter_update, select, select_update, scatter_nd, or gather_nd with an I64 indices tensor containing a value outside the isize range — i.e. an index >= 2^31 (or negative below -2^31) on a 32-bit platform.

Common situations: Running burn-flex on 32-bit targets (wasm32, armv7) with indices produced by arithmetic on large values, uninitialized/garbage index data, or an index tensor built from a model exported from a 64-bit environment.

Related errors

• read_indices: u64 index {v} out of isize range
• read_indices: u32 index {v} out of isize range
• read_indices: unsupported index dtype {:?}
• index {raw} out of bounds for dimension of size {dim_size}
• HannWindow size doesn't fit in i64 range.

AI-assisted analysis of tracel-ai/burn@d16f7ba2ed (2026-09-05). Data as JSON: /api/errors/8abfe34d4919b6d1. Report an issue: GitHub.