Wasmtime GitHub notifications bot (Oct 29 2025 at 07:28): Wasmtime GitHub notifications bot (Oct 29 2025 at 07:28):alexcrichton opened issue #11954:
Fuzzing overnight plus some bisection locally shows that after https://github.com/bytecodealliance/wasmtime/pull/11751 and with https://github.com/bytecodealliance/wasmtime/pull/11953 applied the following fails locally
$ cargo run wast tests/misc_testsuite/component-model/resources.wast --async=false Compiling wasmtime-cli v39.0.0 (/Users/alex/code/wasmtime) Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.18s Running `target/debug/wasmtime wast tests/misc_testsuite/component-model/resources.wast --async=false` Error: failed to run script file 'tests/misc_testsuite/component-model/resources.wast' Caused by: 0: failed directive on tests/misc_testsuite/component-model/resources.wast:28 1: error while executing at wasm backtrace: 0: 0x5d - m!<wasm function 1> note: using the `WASMTIME_BACKTRACE_DETAILS=1` environment variable may show more debugging information 2: wasm trap: wasm `unreachable` instruction executedcc @TartanLlama would you be up for investigating this?
Wasmtime GitHub notifications bot (Oct 29 2025 at 07:28):alexcrichton added the fuzz-bug label to Issue #11954.
Wasmtime GitHub notifications bot (Oct 29 2025 at 07:28):alexcrichton added the wasm-proposal:component-threading label to Issue #11954.
Wasmtime GitHub notifications bot (Oct 29 2025 at 08:46):TartanLlama commented on issue #11954:
Will do!
Wasmtime GitHub notifications bot (Oct 29 2025 at 09:42):TartanLlama commented on issue #11954:
Ah, so this is a case where disabling async changes the handle values of the resources because there's no longer an implicit thread created upon the export call. The test relies upon the resource handle being
2, with the implicit thread filling in the1slot.
Wasmtime GitHub notifications bot (Oct 29 2025 at 09:47):TartanLlama commented on issue #11954:
I guess the spec-consistent behaviour would be to add an entry into the table on sync export calls that will never be used. What do you think?
Wasmtime GitHub notifications bot (Nov 01 2025 at 17:33):alexcrichton commented on issue #11954:
Oof that's tricky! Your intuition matches mine though where a dummy handle feels the way to go here for when threading is disabled in Wasmtime.
Wasmtime GitHub notifications bot (Nov 24 2025 at 16:26):tschneidereit commented on issue #11954:
Instead of landing #12081, should we consider reverting the changes that regressed this until it's fixed? I'd be pretty concerned if we lose fuzzing support for things that we ship at tier-1 for an unknown period of time.
@TartanLlama do you think this is something you could take on before too long? Alternatively, could we revert the changes that break fuzzing until that can be addressed?
Wasmtime GitHub notifications bot (Nov 24 2025 at 17:05):TartanLlama commented on issue #11954:
@tschneidereit I can probably get a fix for this tomorrow
Wasmtime GitHub notifications bot (Nov 25 2025 at 14:33):TartanLlama commented on issue #11954:
Reasoning through what's required here has led me to the fact that we need more machinery added into sync->sync fused adaptors in general for co-op threading bookkeeping, so I won't have a fix for this as fast as I hoped, but this will be my main focus for this week.
Wasmtime GitHub notifications bot (Nov 25 2025 at 14:40):TartanLlama deleted a comment on issue #11954:
Reasoning through what's required here has led me to the fact that we need more machinery added into sync->sync fused adaptors in general for co-op threading bookkeeping, so I won't have a fix for this as fast as I hoped, but this will be my main focus for this week.
Wasmtime GitHub notifications bot (Nov 25 2025 at 14:45):TartanLlama commented on issue #11954:
Reasoning this through has made me realise there needs to be more in the sync->sync fused adaptors to support co-op threading, so I won't have a fix as fast as I hoped. This will be my focus for this week though.
Last updated: Dec 06 2025 at 06:05 UTC