zeroclaw-labs/zeroclaw · error · anyhow::Error

WASM execution error in '{module_name}': {e}

Error message

WASM execution error in '{module_name}': {e}

What it means

execute_module wraps instantiation and execution of the compiled module; when Wasmer returns a runtime error that is not fuel exhaustion (fuel exhaustion is detected separately and reported with its own message), it bails wrapping the underlying Wasmer error text. Typical underlying causes: unreachable trap (panic/abort in the module), out-of-bounds memory access, failed instantiation (missing or mismatched host imports), or memory growth beyond memory_limit_mb trapping.

Source

Thrown at crates/zeroclaw-runtime/src/platform/wasm.rs:209

        // Execute with fuel accounting
        let fuel_before = store.get_fuel().unwrap_or(0);
        let exit_code = match run_fn.call(&mut store, ()) {
            Ok(code) => code,
            Err(e) => {
                // Check if we ran out of fuel (infinite loop protection)
                let fuel_after = store.get_fuel().unwrap_or(0);
                if fuel_after == 0 && fuel > 0 {
                    return Ok(WasmExecutionResult {
                        stdout: String::new(),
                        stderr: format!(
                            "WASM module '{module_name}' exceeded fuel limit ({fuel} ticks) — likely an infinite loop"
                        ),
                        exit_code: -1,
                        fuel_consumed: fuel,
                    });
                }
                bail!("WASM execution error in '{module_name}': {e}");
            }
        };
        let fuel_after = store.get_fuel().unwrap_or(0);
        let fuel_consumed = fuel_before.saturating_sub(fuel_after);

        Ok(WasmExecutionResult {
            stdout: String::new(),  // No WASI stdout yet — pure computation
            stderr: String::new(),
            exit_code,
            fuel_consumed,
        })
    }

    /// Stub for when the `runtime-wasm` feature is not enabled.
    #[cfg(not(feature = "runtime-wasm"))]
    pub fn execute_module(
        &self,
        module_name: &str,

View on GitHub (pinned to 88bb9c8533)

Solutions

1. Read the wrapped Wasmer error {e}: it names the concrete trap (out of bounds memory access, unreachable, etc.)
2. Reproduce outside ZeroClaw: wasmer run tools/wasm/module.wasm with the same inputs, or add a host-shim test harness
3. If imports fail at instantiation, rebuild the module against the host API version matching this runtime
4. If it is memory growth trapping, raise runtime.wasm.memory_limit_mb (within the 4096 cap) or reduce the module's allocation
5. For panics in the tool, build with panic strategy and overflow checks appropriate for production and fix the panic path

Example fix

// before: raw anyhow error surfacing
let result = platform.execute_module("tool", &ws, &caps).await?;

// after: capture context, log fuel, degrade gracefully
match platform.execute_module("tool", &ws, &caps) {
    Ok(r) => { tracing::info!("fuel used: {}", r.fuel_consumed); }
    Err(e) => { tracing::error!("tool failed: {e}"); /* mark tool unhealthy, skip */ }
}

match platform.execute_module(module_name, &ws, &caps) {
    Ok(res) => { tracing::debug!("fuel: {}", res.fuel_consumed); res }
    Err(e) => {
        let msg = e.to_string();
        if msg.contains("exceeded fuel limit") {
            // infinite loop in the module: fix the module or lower fuel; do not blind-retry
        } else if msg.contains("WASM execution error") {
            // trap: log the wrapped Wasmer cause, mark the tool unhealthy, degrade gracefully
        }
        return Err(e);
    }
}

When it happens

Trigger: A bug in the wasm tool causing a Rust panic (unreachable) or OOB access; host-function import ABI mismatch after upgrading the tool or the host; module trying to grow memory past memory_limit_mb; division by zero or failed start function during instantiation.

Common situations: Tool compiled against a different zeroclaw host-API version than the runtime running it; untested edge-case inputs reaching a panic path; memory-heavy modules hitting the configured cap; wasm32-unknown-unknown builds panicking without unwinding (abort → trap).

Related errors

• runtime.wasm.memory_limit_mb must be > 0
• runtime.wasm.memory_limit_mb of {} exceeds the 4 GB safety l
• runtime.wasm.tools_dir cannot be empty
• runtime.wasm.tools_dir must not contain '..' path traversal
• WASM module not found: {} (looked in {})

AI-assisted analysis of zeroclaw-labs/zeroclaw@88bb9c8533 (2026-08-23). Data as JSON: /api/errors/0daba6b599f50245. Report an issue: GitHub.