Repro
import ReleaseSync from "@jitl/quickjs-wasmfile-release-sync";
import { newQuickJSWASMModuleFromVariant } from "quickjs-emscripten-core";
const QuickJS = await newQuickJSWASMModuleFromVariant(ReleaseSync);
const rt = QuickJS.newRuntime();
rt.setMemoryLimit(64 * 1024 * 1024);
const ctx = rt.newContext();
ctx.evalCode(`
const chunks = [];
while (true) { chunks.push("x".repeat(1024 * 1024)); }
`);
Expected
QuickJS throws an OOM error when the limit is exceeded.
Actual
Process memory keeps growing and the host eventually OOMs / runtime crashes. No QuickJS OOM is raised.
Note / workaround
If I build a custom wasm with:
- MPORTED_MEMORY=1
- ALLOW_MEMORY_GROWTH=0
- fixed INITIAL_MEMORY/MAXIMUM_MEMORY
and pass a fixed WebAssembly.Memory via newVariant, the same script consistently throws a QuickJS OOM instead of crashing.
Question
Is there a prebuilt “fixed memory” variant intended for sandbox use, or a recommended way to enforce hard memory caps with the prebuilt wasm?
Repro
Expected
QuickJS throws an OOM error when the limit is exceeded.
Actual
Process memory keeps growing and the host eventually OOMs / runtime crashes. No QuickJS OOM is raised.
Note / workaround
If I build a custom wasm with:
and pass a fixed WebAssembly.Memory via newVariant, the same script consistently throws a QuickJS OOM instead of crashing.
Question
Is there a prebuilt “fixed memory” variant intended for sandbox use, or a recommended way to enforce hard memory caps with the prebuilt wasm?