wasmerio/wasmer · error
64bit memory not implemented yet
Error message
64bit memory not implemented yet
What it means
The wasm-to-IR translator refuses to translate modules that import a WebAssembly memory with the memory64 flag (64-bit index memory, per the memory64 proposal). In parse_import_section, once a MemoryType with memory64=true is encountered, an explicit unimplemented! panic aborts translation instead of producing incorrect Pages(u32) limits. The library only supports 32-bit memories (Pages wraps a u32).
Source
Thrown at lib/compiler/src/translator/sections.rs:154
)?;
}
TypeRef::FuncExact(_) => {
return Err(WasmError::Generic(
"custom-descriptors not implemented yet".to_string(),
));
}
TypeRef::Tag(t) => {
environ.declare_tag_import(t, module_name, field_name)?;
}
TypeRef::Memory(WPMemoryType {
shared,
memory64,
initial,
maximum,
..
}) => {
if memory64 {
unimplemented!("64bit memory not implemented yet");
}
environ.declare_memory_import(
MemoryType {
minimum: Pages(initial as u32),
maximum: maximum.map(|p| Pages(p as u32)),
shared,
},
module_name,
field_name,
)?;
}
TypeRef::Global(ref ty) => {
environ.declare_global_import(
GlobalType {
ty: wptype_to_type(ty.content_type)?,
mutability: ty.mutable.into(),
},
module_name,View on GitHub (pinned to 8c4b9ee9d3)
Solutions
- Rebuild the Wasm module without the memory64 feature (e.g. drop -mmemory64 / use i32 memory limits) so the import is a standard 32-bit memory.
- Change the module to avoid importing 64-bit memory; use linear-memory or shared-buffer shims instead.
- Disallow such modules up front: validate imports before calling translate_module and reject any memory64 import with a clear error.
- Track/upstream support for the memory64 proposal in the compiler and upgrade once implemented.
Example fix
// before (wasm feature flags in build) clang --target=wasm64 -mmemory64 ... // emits memory64 import // after clang --target=wasm32 ... // standard 32-bit memory import
Defensive patterns
Strategy: validation
Validate before calling
// reject modules importing memory64 before translation
fn has_memory64_import(m: &wasmparser::Module) -> bool {
use wasmparser::*;
for payload in Parser::new(0).parse_all(&m.bytes) {
if let Ok(Payload::ImportSection(s)) = payload {
for imp in s {
if let Ok(Import { ty: Type::Memory(mt), .. }) = imp {
if mt.memory64 { return true; }
}
}
}
}
false
}
if has_memory64_import(&module) { return Err("memory64 imports unsupported"); } Try / catch
// keep translate_module behind a catch_unwind and map panics to load errors let result = std::panic::catch_unwind(|| translate_module(&binary, &mut environ)); let module = result.unwrap_or_else(|_| return Err(LoadError::UnsupportedFeature));
Prevention
- Pin wasm feature flags in the toolchain (no memory64) for modules consumed by this runtime
- Add a CI check that validates all shipped wasm binaries for memory64 imports
- Reject unknown/unsupported proposal features at module load time with clear errors
When it happens
Trigger: Translating a module whose import section declares a memory import with the 64-bit flag set (wat: (import ... (memory i64 1)) or memory64 attribute; binary: limits flag bit 0x04 set). Reached via translate_module -> parse_import_section.
Common situations: Compiling Wasm built with toolchains that enable the memory64 proposal (e.g. clang/LLVM -mmemory64, wasm-tools emitting memory64), experimenting with proposal features in wat text, or a library update introducing memory64 modules from third parties.
Related errors
- not yet implemented
- Exception handling is not yet supported in js
- The {val:?} is not yet supported
- Table.copy is not natively supported in Javascript
- The type is not yet supported in the JS Global API
AI-assisted analysis of wasmerio/wasmer@8c4b9ee9d3 (2026-09-01).
Data as JSON: /api/errors/3ba3cf5dcad9e21a.
Report an issue: GitHub.