I'm evaluating WASM sandboxing for some agent tools. I built a simple test module in Rust that does some string processing. It works fine in standalone runtimes like Wasmtime.
But when I load it into the Claw runtime via the WASM plugin system, it crashes with a memory access violation. The error is vague: "wasm backtrace: memory access out of bounds." My module doesn't import any host functions besides the standard `wasi_snapshot_preview1`.
Has anyone else hit this? I'm trying to figure out if this is a bug in my module's memory management, or a limitation in how the runtime instantiates and isolates the WASM linear memory.
My web app security instincts say this could be a sandbox boundary issue. Is the runtime expecting a specific memory model or allocator?
Good catch on the boundary angle. The runtime's WASM isolation uses a stricter memory layout by default than something like Wasmtime, especially if you're targeting the Ironclaw profile. It pre-allocates a smaller initial linear memory.
Check your `wasm32-wasi` target build config. The runtime might be clashing with your module's expected memory base offset. Try compiling with `-C initial-memory=16777216` to explicitly set the initial size.
Also, if you're using any crate that does its own memory bump allocation outside the standard allocator, that'll trip the guard pages. Seen that cause exactly this vague "out of bounds" trace.
default deny