Stream: git-wasmtime

Topic: wasmtime / issue #10007 Calling `store.into_data()` after...

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 11:22):

tomasol added the bug label to Issue #10007.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 11:22):

tomasol opened issue #10007:

Calling store.into_data() after an execution finishes will trigger a panic in this debug assertion of the pooling allocator's drop method.

Test Case

This commit will trigger the bug in a test: https://github.com/tomasol/wasmtime/commit/1d0b9c57bc60ddeb6d39195692df3f4b01525a19

Steps to Reproduce

# in wasmtime repo
git remote add temp git@github.com:tomasol/wasmtime.git
git fetch temp
git checkout temp/pooling-stacks-panic
cargo test --  async_functions::async_host_func_with_pooling_stack

Expected Results

I expect that calling store.into_data() after the execution is OK.

Actual Results

With debug assertions turned on, the destructor of the pooling allocator panics with:

thread 'async_functions::async_host_func_with_pooling_stacks' panicked at crates/wasmtime/src/runtime/vm/instance/allocator/pooling.rs:319:9:
assertion failed: self.stacks.is_empty()

Versions and Environment

Wasmtime version: 28. I did not see it before updating to 28.

Operating system: Linux

Architecture: x86

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 11:22):

tomasol edited issue #10007:

Calling store.into_data() after an execution finishes will trigger a panic in this debug assertion of the pooling allocator's drop method.

Test Case

This commit will trigger the bug in a test: https://github.com/tomasol/wasmtime/commit/1d0b9c57bc60ddeb6d39195692df3f4b01525a19

Steps to Reproduce

# in wasmtime repo
git remote add temp git@github.com:tomasol/wasmtime.git
git fetch temp
git checkout temp/pooling-stacks-panic
cargo test --  async_functions::async_host_func_with_pooling_stack

Expected Results

I expect that calling store.into_data() after the execution is OK.

Actual Results

With debug assertions turned on, the destructor of the pooling allocator panics with:

thread 'async_functions::async_host_func_with_pooling_stacks' panicked at crates/wasmtime/src/runtime/vm/instance/allocator/pooling.rs:319:9:
assertion failed: self.stacks.is_empty()

Versions and Environment

Wasmtime version: 28. I did not see it before updating to 28.

Operating system: Linux

Architecture: x86

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 16:34):

alexcrichton commented on issue #10007:

Thanks for this! This is fixed in https://github.com/bytecodealliance/wasmtime/pull/10009 and I'll backport this to make a 28.0.1 release as well.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 14 2025 at 19:37):

alexcrichton closed issue #10007:

Calling store.into_data() after an execution finishes will trigger a panic in this debug assertion of the pooling allocator's drop method.

Test Case

This commit will trigger the bug in a test: https://github.com/tomasol/wasmtime/commit/1d0b9c57bc60ddeb6d39195692df3f4b01525a19

Steps to Reproduce

# in wasmtime repo
git remote add temp git@github.com:tomasol/wasmtime.git
git fetch temp
git checkout temp/pooling-stacks-panic
cargo test --  async_functions::async_host_func_with_pooling_stack

Expected Results

I expect that calling store.into_data() after the execution is OK.

Actual Results

With debug assertions turned on, the destructor of the pooling allocator panics with:

thread 'async_functions::async_host_func_with_pooling_stacks' panicked at crates/wasmtime/src/runtime/vm/instance/allocator/pooling.rs:319:9:
assertion failed: self.stacks.is_empty()

Versions and Environment

Wasmtime version: 28. I did not see it before updating to 28.

Operating system: Linux

Architecture: x86

Last updated: Jan 24 2025 at 00:11 UTC