Stream: git-wasmtime

Topic: wasmtime / issue #6493 Crash when async yielding is enabled

view this post on Zulip Wasmtime GitHub notifications bot (Jun 01 2023 at 10:13):

vigoo opened issue #6493:

Test Case

I created a small repo that reproduces the issue. Tried to make it as minimal as possible but as I'm not sure what exactly the reason is, I stayed with a realistic example that is similar to how we use wasmtime.

The repo is here: https://github.com/vigoo/wasmtime-crash-repro

component contains a project to be compiled with cargo component build - it's basically just a sleep
host initializes wasmtime and contains a fake wasi implementation using async bindings which only does an async sleep in the poll_oneoff implementation. Then it spawns 100 instances and runs them in parallel.

If either epoch based async yielding, or fuel based async yielding is enabled, I get a random crash from traphandlers.rs:

Steps to Reproduce

cargo component build in the component directory
cargo run in the host directory

Expected Results

All the 100 instances run, sleep for 2 seconds and finish.
By commenting out the epoch related lines in main.rs it finishes successfully.

Actual Results

Panic in traphandlers.rs

Versions and Environment

Tried it with both the stable release and an (almost) latest master and it happens in both.
Operating system: OSX Ventura
Architecture: arm64

Extra Info

view this post on Zulip Wasmtime GitHub notifications bot (Jun 01 2023 at 10:13):

vigoo labeled issue #6493:

Test Case

I created a small repo that reproduces the issue. Tried to make it as minimal as possible but as I'm not sure what exactly the reason is, I stayed with a realistic example that is similar to how we use wasmtime.

The repo is here: https://github.com/vigoo/wasmtime-crash-repro

component contains a project to be compiled with cargo component build - it's basically just a sleep
host initializes wasmtime and contains a fake wasi implementation using async bindings which only does an async sleep in the poll_oneoff implementation. Then it spawns 100 instances and runs them in parallel.

If either epoch based async yielding, or fuel based async yielding is enabled, I get a random crash from traphandlers.rs:

Steps to Reproduce

cargo component build in the component directory
cargo run in the host directory

Expected Results

All the 100 instances run, sleep for 2 seconds and finish.
By commenting out the epoch related lines in main.rs it finishes successfully.

Actual Results

Panic in traphandlers.rs

Versions and Environment

Tried it with both the stable release and an (almost) latest master and it happens in both.
Operating system: OSX Ventura
Architecture: arm64

Extra Info

view this post on Zulip Wasmtime GitHub notifications bot (Jun 01 2023 at 15:27):

alexcrichton edited issue #6493:

Test Case

I created a small repo that reproduces the issue. Tried to make it as minimal as possible but as I'm not sure what exactly the reason is, I stayed with a realistic example that is similar to how we use wasmtime.

The repo is here: https://github.com/vigoo/wasmtime-crash-repro

component contains a project to be compiled with cargo component build - it's basically just a sleep
host initializes wasmtime and contains a fake wasi implementation using async bindings which only does an async sleep in the poll_oneoff implementation. Then it spawns 100 instances and runs them in parallel.

If either epoch based async yielding, or fuel based async yielding is enabled, I get a random crash from traphandlers.rs:

thread '   4:        0x105e81b04 - core::fmttokio-runtime-worker::' panicked at 'writeassertion failed: std::ptr::eq(head, self)::', h34766cf8fff7af1e/Users/vigoo/.cargo/registry/src/github.com-1ecc6299db9ec823/wasmtime-runtime-9.0.3/src/traphandlers.rs

Steps to Reproduce

cargo component build in the component directory
cargo run in the host directory

Expected Results

All the 100 instances run, sleep for 2 seconds and finish.
By commenting out the epoch related lines in main.rs it finishes successfully.

Actual Results

Panic in traphandlers.rs

Versions and Environment

Tried it with both the stable release and an (almost) latest master and it happens in both.
Operating system: OSX Ventura
Architecture: arm64

Extra Info

view this post on Zulip Wasmtime GitHub notifications bot (Jun 01 2023 at 18:48):

alexcrichton commented on issue #6493:

Thanks for the report! I'm digging into this and trying to figure out what's going on. It's proving elusive so it may take me a moment to figure out the best fix for this.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 01 2023 at 18:49):

alexcrichton labeled issue #6493:

Test Case

I created a small repo that reproduces the issue. Tried to make it as minimal as possible but as I'm not sure what exactly the reason is, I stayed with a realistic example that is similar to how we use wasmtime.

The repo is here: https://github.com/vigoo/wasmtime-crash-repro

component contains a project to be compiled with cargo component build - it's basically just a sleep
host initializes wasmtime and contains a fake wasi implementation using async bindings which only does an async sleep in the poll_oneoff implementation. Then it spawns 100 instances and runs them in parallel.

If either epoch based async yielding, or fuel based async yielding is enabled, I get a random crash from traphandlers.rs:

thread '   4:        0x105e81b04 - core::fmttokio-runtime-worker::' panicked at 'writeassertion failed: std::ptr::eq(head, self)::', h34766cf8fff7af1e/Users/vigoo/.cargo/registry/src/github.com-1ecc6299db9ec823/wasmtime-runtime-9.0.3/src/traphandlers.rs

Steps to Reproduce

cargo component build in the component directory
cargo run in the host directory

Expected Results

All the 100 instances run, sleep for 2 seconds and finish.
By commenting out the epoch related lines in main.rs it finishes successfully.

Actual Results

Panic in traphandlers.rs

Versions and Environment

Tried it with both the stable release and an (almost) latest master and it happens in both.
Operating system: OSX Ventura
Architecture: arm64

Extra Info

view this post on Zulip Wasmtime GitHub notifications bot (Jun 01 2023 at 22:21):

alexcrichton commented on issue #6493:

Ok I've isolated this to a failing unit test. I wrote a fix for that and was about to make a PR until I realized that the fix wasn't complete. I've written a second test to trigger that failure and I'll work more tomorrow on a complete fix for this.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 01 2023 at 22:22):

alexcrichton commented on issue #6493:

I'll also note that as a heads up this is a memory unsoundness issue. We won't be issuing a CVE due to our policy right now as the component model support is "tier 3" which doesn't get CVEs allocated. If that impacts your usage though you may wish to be aware.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 02 2023 at 05:55):

vigoo commented on issue #6493:

Thanks for the updates!

view this post on Zulip Wasmtime GitHub notifications bot (Jun 02 2023 at 16:07):

alexcrichton commented on issue #6493:

Ok I believe that https://github.com/bytecodealliance/wasmtime/pull/6509 should address this issue for now

view this post on Zulip Wasmtime GitHub notifications bot (Jun 02 2023 at 21:35):

fitzgen closed issue #6493:

Test Case

I created a small repo that reproduces the issue. Tried to make it as minimal as possible but as I'm not sure what exactly the reason is, I stayed with a realistic example that is similar to how we use wasmtime.

The repo is here: https://github.com/vigoo/wasmtime-crash-repro

component contains a project to be compiled with cargo component build - it's basically just a sleep
host initializes wasmtime and contains a fake wasi implementation using async bindings which only does an async sleep in the poll_oneoff implementation. Then it spawns 100 instances and runs them in parallel.

If either epoch based async yielding, or fuel based async yielding is enabled, I get a random crash from traphandlers.rs:

thread '   4:        0x105e81b04 - core::fmttokio-runtime-worker::' panicked at 'writeassertion failed: std::ptr::eq(head, self)::', h34766cf8fff7af1e/Users/vigoo/.cargo/registry/src/github.com-1ecc6299db9ec823/wasmtime-runtime-9.0.3/src/traphandlers.rs

Steps to Reproduce

cargo component build in the component directory
cargo run in the host directory

Expected Results

All the 100 instances run, sleep for 2 seconds and finish.
By commenting out the epoch related lines in main.rs it finishes successfully.

Actual Results

Panic in traphandlers.rs

Versions and Environment

Tried it with both the stable release and an (almost) latest master and it happens in both.
Operating system: OSX Ventura
Architecture: arm64

Extra Info

Last updated: Dec 23 2024 at 12:05 UTC