tracel-ai/burn · critical

Failed to get data for tensor '{}': {:?}

Error message

Failed to get data for tensor '{}': {:?}

What it means

In burn-store's safetensors writer, `View::data` must return the tensor's bytes but has no error channel, so a failure while materializing tensor data (`to_bytes()`) cannot be propagated and instead panics, naming the tensor. This typically wraps an underlying store error (device read failure, unsupported dtype/layout, IO problem) that the safetensors export path cannot report gracefully.

Source

Thrown at crates/burn-store/src/safetensors/store.rs:620

impl safetensors::View for PackTensorView {
    fn dtype(&self) -> safetensors::Dtype {
        // Convert from burn dtype to safetensors dtype
        dtype_to_safetensors(self.0.dtype).unwrap_or(safetensors::Dtype::F32)
    }

    fn shape(&self) -> &[usize] {
        &self.0.shape
    }

    fn data(&self) -> alloc::borrow::Cow<'_, [u8]> {
        // Only materialize data when actually needed for serialization
        // `View::data` has no error channel, so this is the one place a materialization
        // failure cannot be returned. Name the tensor at least, since the writer's own
        // annotation is not reached from here.
        let bytes = self
            .0
            .to_bytes()
            .unwrap_or_else(|e| panic!("Failed to get data for tensor '{}': {:?}", self.0.name, e));
        alloc::borrow::Cow::Owned(bytes.deref().to_vec())
    }

    fn data_len(&self) -> usize {
        // Known from the descriptor, without drawing the bytes
        self.0.byte_len()
    }
}

impl ModuleStore for SafetensorsStore {
    type Error = SafetensorsStoreError;

    fn collect_from<M: ModuleSnapshot>(&mut self, module: &M) -> Result<(), Self::Error> {
        // Invalidate cache since we're writing new data
        match self {
            #[cfg(feature = "std")]
            Self::File(p) => p.tensors_cache = None,
            Self::Memory(p) => p.tensors_cache = None,

View on GitHub (pinned to d16f7ba2ed)

Solutions

  1. Ensure all tensors are on an accessible device and synchronized before export (e.g. move to CPU / call sync).
  2. Catch the underlying cause from the panic message (tensor name + inner error) and fix the reported backend/IO issue.
  3. If exporting from a remote backend, read tensors locally first, then save with SafetensorsStore.
  4. Check the dtype is supported by safetensors and convert unsupported dtypes before export.

Example fix

// before
model.save(SafetensorsStore::from_file("model.safetensors"))?; // panics if GPU tensor unreadable
// after
let model = model.to_device(&Default::default()); // move to CPU first
model.verify()?; // ensure data is materialized
model.save(SafetensorsStore::from_file("model.safetensors"))?;
Defensive patterns

Strategy: validation

Validate before calling

// verify data is materialized and readable before export
model.verify()?;
for param in model.parameters() {
    assert!(param.is_ready(), "tensor not ready for export");
}

Try / catch

// panic escapes View::data; guard the save call
let result = std::panic::catch_unwind(AssertUnwindSafe(||
    model.save(SafetensorsStore::from_file("model.safetensors"))
));

Prevention

When it happens

Trigger: Exporting a module/tensor to safetensors (ModuleSnapshot / record saving via SafetensorsStore) when `to_bytes()` on the underlying tensor view fails — e.g. the tensor data lives on a device that cannot be read, or the backend returns an error while gathering data.

Common situations: Saving a model whose tensors reside on a GPU that is unavailable/disconnected; exporting a lazily-computed or remote (burn-remote) tensor whose fetch fails; dtype/shape combinations unsupported by the safetensors exporter.

Related errors


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