Stream: git-wasmtime

Topic: wasmtime / issue #12510 [CM async] misbehavior dropping b...

Wasmtime GitHub notifications bot (Feb 04 2026 at 00:47):

lukewagner opened issue #12510:

This weird test (currently on main) drops a borrowed handle when the current task is different from the task that initially received the borrowed handle. To handle this case correctly, the runtime can't decrement the current task's "number of outstanding borrowed handles" but must instead derive the task from the borrowed handle being dropped.

In more detail: this is the function that receives the borrowed handle and this is the function that drops it. When the latter function returns, it traps with "borrow handles still remain at the end of the call"; I'm guessing because it decremented its own task's counter which underflowed from 0 to non-0.

Wasmtime GitHub notifications bot (Feb 04 2026 at 00:47):

lukewagner added the bug label to Issue #12510.

Wasmtime GitHub notifications bot (Feb 04 2026 at 01:52):

alexcrichton commented on issue #12510:

In debug mode I get:

$ cargo run wast foo.wast -W component-model-async
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.10s
     Running `target/debug/wasmtime wast foo.wast -W component-model-async`

thread 'main' (3151422) panicked at crates/wasmtime/src/runtime/vm/component/resources.rs:247:17:
attempt to subtract with overflow
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

so agreed this is an underflow of the wrong counter!

Wasmtime GitHub notifications bot (Feb 04 2026 at 01:59):

alexcrichton added the wasm-proposal:component-model-async label to Issue #12510.

Wasmtime GitHub notifications bot (Feb 09 2026 at 20:05):

alexcrichton assigned alexcrichton to issue #12510.

Wasmtime GitHub notifications bot (Feb 10 2026 at 03:41):

alexcrichton closed issue #12510:

This weird test (currently on main) drops a borrowed handle when the current task is different from the task that initially received the borrowed handle. To handle this case correctly, the runtime can't decrement the current task's "number of outstanding borrowed handles" but must instead derive the task from the borrowed handle being dropped.

In more detail: this is the function that receives the borrowed handle and this is the function that drops it. When the latter function returns, it traps with "borrow handles still remain at the end of the call"; I'm guessing because it decremented its own task's counter which underflowed from 0 to non-0.

Last updated: Feb 24 2026 at 04:36 UTC