Stream: git-wasmtime

Topic: wasmtime / issue #7502 Panic in fuel_remaining when all f...

Wasmtime GitHub notifications bot (Nov 08 2023 at 19:29):

coolreader18 added the bug label to Issue #7502.

Wasmtime GitHub notifications bot (Nov 08 2023 at 19:29):

coolreader18 opened issue #7502:

Test Case / Reproduction

use wasmtime::*;
fn main() -> Result<()> {
    let engine = Engine::new(Config::new().consume_fuel(true))?;
    let mut store = Store::new(&engine, ());
    let module = Module::new(
        &engine,
        r#"
(module
  (func $add2 (export "add2") (param $n i32) (result i32)
    (i32.add (local.get $n) (i32.const 2))
  )
)
        "#,
    )?;
    let instance = Instance::new(&mut store, &module, &[])?;

    let add2 = instance.get_typed_func::<i32, i32>(&mut store, "add2")?;

    store.add_fuel(6)?;
    dbg!(store.fuel_remaining()); // fuel_remaining = 6
    add2.call(&mut store, 10)?;   // succeeds
    dbg!(store.fuel_remaining()); // fuel_remaining = 2
    add2.call(&mut store, 10)?;   // succeeds
    dbg!(store.fuel_remaining()); // panicked at wasmtime-14.0.4/src/store.rs:1456:39:
                                  // called `Result::unwrap()` on an `Err` value: TryFromIntError(())

    Ok(())
}

Expected Results

store.fuel_remaining() = Some(0)

Actual Results

thread 'main' panicked at /home/coolreader18/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wasmtime-14.0.4/src/store.rs:1456:39:
called `Result::unwrap()` on an `Err` value: TryFromIntError(())

Versions and Environment

Wasmtime version or commit: 14.0.4

Operating system: Arch Linux

Architecture: x86_64

Extra Info

Obviously I know this'll be fixed in 15.0.0 anyway since the fuel apis will be totally different and afaict they don't have this unwrap, but this is really unintuitive behavior that means that any interaction with the fuel apis could possibly lead to a panic. This bug isn't really a huge issue for me personally - I _have_ seen at least one instance of this in production logs, but the system was resilient enough to handle the panic fine - but I just figured it might be something you guys might want to consider putting out a patch release about. I think the solution would be probably to just .unwrap_or(0) instead of .unwrap().

Wasmtime GitHub notifications bot (Nov 08 2023 at 21:16):

alexcrichton commented on issue #7502:

Thanks for the report! If you'd like we can certainly do a 14.0.5 release for this, it's pretty low-effort on our part. Even if this is already fixed on 15.0.x I'll take your test and add it to our test suite to make sure we don't regress in the future.

Wasmtime GitHub notifications bot (Nov 20 2023 at 18:06):

coolreader18 closed issue #7502:

Test Case / Reproduction

use wasmtime::*;
fn main() -> Result<()> {
    let engine = Engine::new(Config::new().consume_fuel(true))?;
    let mut store = Store::new(&engine, ());
    let module = Module::new(
        &engine,
        r#"
(module
  (func $add2 (export "add2") (param $n i32) (result i32)
    (i32.add (local.get $n) (i32.const 2))
  )
)
        "#,
    )?;
    let instance = Instance::new(&mut store, &module, &[])?;

    let add2 = instance.get_typed_func::<i32, i32>(&mut store, "add2")?;

    store.add_fuel(6)?;
    dbg!(store.fuel_remaining()); // fuel_remaining = 6
    add2.call(&mut store, 10)?;   // succeeds
    dbg!(store.fuel_remaining()); // fuel_remaining = 2
    add2.call(&mut store, 10)?;   // succeeds
    dbg!(store.fuel_remaining()); // panicked at wasmtime-14.0.4/src/store.rs:1456:39:
                                  // called `Result::unwrap()` on an `Err` value: TryFromIntError(())

    Ok(())
}

Expected Results

store.fuel_remaining() = Some(0)

Actual Results

thread 'main' panicked at /home/coolreader18/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wasmtime-14.0.4/src/store.rs:1456:39:
called `Result::unwrap()` on an `Err` value: TryFromIntError(())

Versions and Environment

Wasmtime version or commit: 14.0.4

Operating system: Arch Linux

Architecture: x86_64

Extra Info

Obviously I know this'll be fixed in 15.0.0 anyway since the fuel apis will be totally different and afaict they don't have this unwrap, but this is really unintuitive behavior that means that any interaction with the fuel apis could possibly lead to a panic. This bug isn't really a huge issue for me personally - I _have_ seen at least one instance of this in production logs, but the system was resilient enough to handle the panic fine - but I just figured it might be something you guys might want to consider putting out a patch release about. I think the solution would be probably to just .unwrap_or(0) instead of .unwrap().

Wasmtime GitHub notifications bot (Nov 20 2023 at 18:06):

coolreader18 commented on issue #7502:

Oh, meant to respond earlier, but 15.0 is out now, so I'll just use that. Thanks for adding the test for this!

Last updated: Dec 23 2024 at 13:07 UTC