wasmerio/wasmer · error

wasmer_env_set_memory() is not supported

Error message

wasmer_env_set_memory() is not supported

What it means

wasi_env_set_memory is a deprecated stub kept only for C API source compatibility. Setting the WASI environment's memory directly is no longer possible because WASIX changes made memory management owned elsewhere. Any call unconditionally panics; memory customization must now go through the builder or runtime APIs.

Source

Thrown at lib/c-api/src/wasm_c_api/wasi/mod.rs:245

}

/// Delete a [`wasi_env_t`].
#[unsafe(no_mangle)]
pub extern "C" fn wasi_env_delete(state: Option<Box<wasi_env_t>>) {
    if let Some(mut env) = state {
        let mut store = unsafe { env.store.store_mut() };
        env.inner.on_exit(&mut store, None);
    }
}

/// Set the memory on a [`wasi_env_t`].
// NOTE: Only here to not break the C API.
// This was previously supported, but is no longer possible due to WASIX changes.
// Customizing memories should be done through the builder or the runtime.
#[unsafe(no_mangle)]
#[deprecated(since = "4.0.0")]
pub unsafe extern "C" fn wasi_env_set_memory(_env: &mut wasi_env_t, _memory: &wasm_memory_t) {
    panic!("wasmer_env_set_memory() is not supported");
}

#[unsafe(no_mangle)]
pub unsafe extern "C" fn wasi_env_read_stdout(
    env: &mut wasi_env_t,
    buffer: *mut c_char,
    buffer_len: usize,
) -> isize {
    let inner_buffer = unsafe { slice::from_raw_parts_mut(buffer as *mut _, buffer_len) };
    let store = unsafe { env.store.store() };

    let stdout = {
        let data = env.inner.data(&store);
        data.stdout()
    };

    if let Ok(mut stdout) = stdout {
        if let Some(stdout) = stdout.as_mut() {

View on GitHub (pinned to 8c4b9ee9d3)

Solutions

1. Remove the wasi_env_set_memory call entirely; use wasi_env_new / builder APIs to configure memory.
2. Configure memory via the WASI environment builder or runtime (e.g. set memory sizes at build time) instead of replacing it after creation.
3. Treat the deprecation attribute as a build-time signal and fix callers before upgrading to 4.x.
4. If you need a specific memory, attach it through the store/runtime plumbing rather than the WASI env.

Example fix

// before
wasi_env_set_memory(env, memory); // panics since 4.0
// after
wasi_config_t *config = wasi_config_new();
wasi_env_t *env = wasi_env_new(store, config); // configure via builder/runtime

// C: refuse to call the deprecated stub
#ifdef WASMER_VERSION_MAJOR
# if WASMER_VERSION_MAJOR >= 4
#  error "wasi_env_set_memory was removed in Wasmer 4.x; use the builder API"
# endif
#endif

// Catch around migration shims during upgrade
std::panic::catch_unwind(|| unsafe { wasi_env_set_memory(env, memory) })
    .expect_err("wasi_env_set_memory is not supported; migrate to builder API");

When it happens

Trigger: Calling wasi_env_set_memory(env, memory) — the function body is an unconditional panic. There is no path that succeeds.

Common situations: Code written against Wasmer 3.x that customized WASI memory by replacement, recompiled against 4.0+; legacy C API samples or vendored bindings still calling the deprecated symbol; ignoring the since-4.0.0 deprecation warning until runtime.

Related errors

• not a `sys` backend!
• Unsupported backend kind {v:?}
• unimplemented operator {operator:?}
• Unable to determine the wasmer dir: {e}
• cannot create debug directory: {}

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