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
- Ensure all tensors are on an accessible device and synchronized before export (e.g. move to CPU / call sync).
- Catch the underlying cause from the panic message (tensor name + inner error) and fix the reported backend/IO issue.
- If exporting from a remote backend, read tensors locally first, then save with SafetensorsStore.
- 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
- Move tensors to an accessible device (CPU) before saving
- Call sync()/verify() on the model before export
- Avoid exporting tensors from remote/lazy backends directly
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
- Can save model checkpoint.
- capture tensor operations must run inside CaptureDevice::cap
- Capture tensors do not support autodiff
- Autodiff should not wrap an autodiff tensor.
- Requires autodiff tensor.
AI-assisted analysis of tracel-ai/burn@d16f7ba2ed (2026-09-05).
Data as JSON: /api/errors/a769aeb8ae40ca5a.
Report an issue: GitHub.