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

  1. 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.
  2. Change the module to avoid importing 64-bit memory; use linear-memory or shared-buffer shims instead.
  3. Disallow such modules up front: validate imports before calling translate_module and reject any memory64 import with a clear error.
  4. 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

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


AI-assisted analysis of wasmerio/wasmer@8c4b9ee9d3 (2026-09-01). Data as JSON: /api/errors/3ba3cf5dcad9e21a. Report an issue: GitHub.