adamrk opened issue #14161:
OSS fuzz failure: https://oss-fuzz.com/testcase-detail/4690035493109760
The following wast fails with fuel set to
18446744073709551615:(module (memory i64 1) (func (export "fill64") (param $dst i64) (param $len i64) local.get $dst i32.const 0 local.get $len memory.fill)) ;; Drains fuel to ~0 but still traps out-of-bounds correctly -> this passes. (assert_trap (invoke "fill64" (i64.const 0) (i64.const -1)) "out of bounds") ;; No fuel left: traps "all fuel consumed" instead of "out of bounds" -> FAILS. (assert_trap (invoke "fill64" (i64.const 0) (i64.const -1)) "out of bounds")Run it with
cargo run -- wast -Wfuel=18446744073709551615 memory_fill.reduced.wast:$ cargo run -- wast -Wfuel=18446744073709551615 memory_fill.reduced.wast Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.35s Running `target/debug/wasmtime wast -Wfuel=18446744073709551615 memory_fill.reduced.wast` Error: failed to run script file 'memory_fill.reduced.wast' Caused by: 0: failed directive on memory_fill.reduced.wast:35 1: expected 'out of bounds', got 'error while executing at wasm backtrace: 0: 0x30 - wasm-function[0] at ./memory_fill.reduced.wast:30:5 Caused by: wasm trap: all fuel consumed by WebAssembly 'This is the same as the issue described by @alexcrichton here: https://github.com/bytecodealliance/wasmtime/issues/14047#issuecomment-5297814096
adamrk added the bug label to Issue #14161.
adamrk added the fuzz-bug label to Issue #14161.
adamrk commented on issue #14161:
How about doing the charge afterward based on both the bulk operation size and the return value? So the fuel charge would be determined at runtime even if the size is
const, but we could keep the existing logic for "small"constsizes.
alexcrichton commented on issue #14161:
That sounds like a great idea to me! It's pretty arbitrary to check either before or after so I think it's basically equivalent
adamrk commented on issue #14161:
Or maybe even consuming within the libcall is better since we'd need to do that anyway to handle https://github.com/bytecodealliance/wasmtime/issues/14047#issuecomment-5297814096 . For now we could just consume the fuel in the libcall and let cranelift generated code decide if it wants to check for fuel/epoch after the call resolves.
alexcrichton commented on issue #14161:
Consuming fuel I think would be easy enough, but actually injecting a yield point for epochs and/or refueling situations I think may be relatively difficult, and for that I suspect it'll be easiest/best to leave it to the compiled code to figure out
alexcrichton added the wasmtime:fuel label to Issue #14161.
Last updated: Aug 30 2026 at 09:07 UTC