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

runtime.wasm.memory_limit_mb of {} exceeds the 4 GB safety l

Error message

runtime.wasm.memory_limit_mb of {} exceeds the 4 GB safety limit for 32-bit WASM

What it means

The second WASM config guard: memory_limit_mb above 4096 is rejected because it exceeds the 4 GB address space of 32-bit WASM memories. A limit larger than what a wasm32 module can ever address is either a unit mistake (bits vs bytes, MB vs GB) or a mispaste, so validate_config refuses it rather than silently clamping.

Source

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

    pub fn with_workspace(config: WasmRuntimeConfig, workspace_dir: PathBuf) -> Self {
        Self {
            config,
            workspace_dir: Some(workspace_dir),
        }
    }

    /// Check if the WASM runtime feature is available in this build.
    pub fn is_available() -> bool {
        cfg!(feature = "runtime-wasm")
    }

    /// Validate the WASM config for common misconfigurations.
    pub fn validate_config(&self) -> Result<()> {
        if self.config.memory_limit_mb == 0 {
            bail!("runtime.wasm.memory_limit_mb must be > 0");
        }
        if self.config.memory_limit_mb > 4096 {
            bail!(
                "runtime.wasm.memory_limit_mb of {} exceeds the 4 GB safety limit for 32-bit WASM",
                self.config.memory_limit_mb
            );
        }
        if self.config.tools_dir.is_empty() {
            bail!("runtime.wasm.tools_dir cannot be empty");
        }
        // Verify tools directory doesn't escape workspace
        if self.config.tools_dir.contains("..") {
            bail!("runtime.wasm.tools_dir must not contain '..' path traversal");
        }
        Ok(())
    }

    /// Resolve the absolute path to the WASM tools directory.
    pub fn tools_dir(&self, workspace_dir: &Path) -> PathBuf {
        workspace_dir.join(&self.config.tools_dir)
    }

View on GitHub (pinned to 88bb9c8533)

Solutions

  1. Cap the setting at 4096 or below — for wasm32 that is the entire addressable maximum anyway
  2. Double-check units: the field is megabytes, so 4096 already means 4 GB
  3. If a tool genuinely needs more memory than 4 GB, it cannot run as a 32-bit WASM module — run it under runtime.kind = "native"
  4. Keep the value realistic for actual modules (most tools need tens to hundreds of MB)

Example fix

# before
[runtime.wasm]
memory_limit_mb = 16384

# after
[runtime.wasm]
memory_limit_mb = 512
Defensive patterns

Strategy: validation

Validate before calling

const MAX_WASM_MB: u32 = 4096;
if cfg.memory_limit_mb > MAX_WASM_MB {
    // reject at config load with a unit hint (field is megabytes; 4096 == 4 GB == wasm32 max)
}

Try / catch

if let Err(e) = platform.validate_config() {
    if e.to_string().contains("4 GB safety limit") {
        // unit/typo problem: clamp to <=4096 or move the workload to native runtime
    }
}

Prevention

When it happens

Trigger: Setting memory_limit_mb = 8192 or 16384 copying native-container habits; entering a byte count (4294967296) instead of megabytes; upgrading configs from systems that expressed limits differently.

Common situations: Teams used to 64-bit native runtimes requesting tens of GB; unit confusion between MiB/GB; values pasted from infrastructure docs for container memory limits.

Related errors


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