Stream: git-wasmtime

Topic: wasmtime / issue #11427 Huge array allocations are timing...

Wasmtime GitHub notifications bot (Aug 13 2025 at 17:22):

alexcrichton opened issue #11427:

There's a timeout on oss-fuzz right now in the differential fuzzer. Debugging this it looks like huge arrays are being allocated in wasm and limits aren't kicking into effect. I've verified that the memory limits aren't being exceeded as all allocations fall under our 1G limit for stores.

What appears to be happening is that Cranelift-generated wasm code is taking quite a long time to initialize the array in question. This is under Pulley which is also a slowdown hit too. Differential fuzzing relies on in-wasm fuel counters to ensure execution doesn't take too long and those counters aren't taking into account these "expensive" instructions.

There's a few things I've noticed here and some ideas for solving this:

• Compiled code for array.new_default has a loop which doesn't contain fuel/epoch checks. That will help in the general case but won't help here because while fuel is enabled for this fuzz test case it's given infinite fuel and relies on in-wasm fuel instead.
• Wasm-smith could in theory decrement the size of array.new_default from the in-wasm fuel counter before executing array.new_default, but it doesn't currently.
• Host-side allocations of large arrays don't have any await/fuel/epoch checks meaning that large allocations take take a significant chunk of time.

Wasmtime GitHub notifications bot (Aug 13 2025 at 17:22):

alexcrichton added the fuzz-bug label to Issue #11427.

Wasmtime GitHub notifications bot (Aug 13 2025 at 17:22):

alexcrichton added the wasm-proposal:gc label to Issue #11427.

Last updated: Dec 06 2025 at 06:05 UTC