wasmerio/wasmer · error

cloning JavaScript shared memory should not fail

Error message

cloning JavaScript shared memory should not fail

What it means

This panic comes from a Clone impl for a VM memory wrapper (VMMemory). For the JavaScript backend, the underlying shared memory is backed by a JS object that cannot be Clone'd on all runtimes; if try_clone() fails the code deliberately panics because sharing cloned memory across VM instances is assumed to always work for JS shared memory. It indicates an internal invariant of the js feature's memory sharing broke.

Source

Thrown at lib/api/src/vm/impls.rs:80

            Self::V8(s) => s.as_shared().map(VMSharedMemory::V8),
            #[cfg(feature = "js")]
            Self::Js(s) => s.try_clone().map(VMSharedMemory::Js),
        }
    }
}

impl VMSharedMemory {
    /// Clones this shared memory handle.
    pub(crate) fn clone(&self) -> Self {
        match self {
            #[cfg(feature = "sys")]
            Self::Sys(s) => Self::Sys(s.clone()),
            #[cfg(feature = "v8")]
            Self::V8(s) => Self::V8(s.clone()),
            #[cfg(feature = "js")]
            Self::Js(s) => Self::Js(
                s.try_clone()
                    .expect("cloning JavaScript shared memory should not fail"),
            ),
        }
    }

    pub(crate) fn into_vm_memory(self, store: &mut impl AsStoreMut) -> VMMemory {
        match self {
            #[cfg(feature = "sys")]
            Self::Sys(s) => VMMemory::Sys(s.into()),
            #[cfg(feature = "v8")]
            Self::V8(s) => {
                let mut store = store.as_store_mut();
                VMMemory::V8(s.into_vm_memory(store.inner.store.as_v8_mut()))
            }
            #[cfg(feature = "js")]
            Self::Js(s) => VMMemory::Js(s),
        }
    }
}

View on GitHub (pinned to 8c4b9ee9d3)

Solutions

1. Enable cross-origin isolation (COOP/COEP headers) so SharedArrayBuffer is available in the browser runtime
2. Rebuild without the js feature (or with v8/sys backend) if you do not need JS shared memory
3. Upgrade wasmer; this is an internal invariant panic, so check for a newer version with a fallible clone
4. Avoid cloning memory handles across realms/VM instances; recreate the memory instead

Example fix

// before (panic path)
let mem2 = memory.clone();
// after: create a fresh memory instead of cloning across runtimes
let mem2 = Memory::new(&store, memory_ty)?;

// Ensure the runtime supports SharedArrayBuffer before using the js backend
if (typeof SharedArrayBuffer === 'undefined') {
  throw new Error('SharedArrayBuffer unavailable; enable COOP/COEP or use a non-js backend');
}

fn is_js_memory(mem: &VMMemory) -> bool { matches!(mem, VMMemory::Js(_)) }

// Clone of VMMemory panics rather than returning Result; isolate it
let mem2 = std::panic::catch_unwind(|| mem.clone())
    .map_err(|_| anyhow::anyhow!("JS shared memory clone failed"))?;

When it happens

Trigger: Cloning a VMMemory::Js variant via .clone() (e.g. when cloning a Store, Instance handle, or memory handle to share across VMs) when the underlying JS SharedArrayBuffer/typed array cannot be cloned in the current JS runtime (e.g. cross-realm object or missing SharedArrayBuffer support).

Common situations: Running wasmer compiled with feature=js inside a restricted WASM-in-browser environment where SharedArrayBuffer is unavailable (no COOP/COEP headers), or cloning memory handles across JS compartments.

Related errors

• unimplemented operator {operator:?}
• global #{} is a constant
• Cannot load reference type
• Unhandled inner case
• Exception handling is not yet supported in js

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