Closed pimeys closed 3 months ago
To be fair, I have a separate test project that does not call the guest from rust tests. I tried to load the env var in there inside the guest, and it worked as expected.
If I understand it correctly, the issue is here:
0: 0x1e3cf8 - wit-component:adapter:wasi_snapshot_preview1!wasi_snapshot_preview1::macros::print::h7cf3bf67e3d70272
1: 0x1e28c9 - wit-component:adapter:wasi_snapshot_preview1!wasi_snapshot_preview1::BumpArena::alloc::he1fbf182c547cac8
2: 0x1e246e - wit-component:adapter:wasi_snapshot_preview1!cabi_import_realloc
3: 0x1e6374 - wit-component:shim!indirect-wasi:cli/environment@0.2.0-get-environment
4: 0x1e2f80 - wit-component:adapter:wasi_snapshot_preview1!wasi_snapshot_preview1::State::get_environment::h3dc87564e4fc1678
To be precise the adapter for indirect-wasi:cli/environment@0.2.0-get-environment
calls back into your wasm component to allocate memory. While this happens it is not allowed to call any imports, but wasi_snapshot_preview1::macros::print
is called here. As for why that happens, it is likely that BumpArena::alloc
ran out of memory and tried to panic. If so this should have been fixed by https://github.com/bytecodealliance/wasmtime/pull/8594. You will need to update cargo-component to get this fix though as the bug is inside the wasip1 to wasip2 adapter which cargo-component includes in the wasm component itself.
I believe that @bjorn3 is correct (thanks!), and this is definitely a frustration I've had in the past with debugging the adapter too.
I've confirmed that by default if the environment variable block is too big then cargo-component-produced components fail with this error (as the allocation is too big), but if I use package.metadata.component.adapter
to point to the latest version of the adapter it works.
Given that I think that this should be fixable by updating the adapter you're using. Would you be able to test that out @pimeys?
Sure, my work on this continues tomorrow. Could you point me to instructions on how exactly I should do this? Eventually our users will also need to build these modules, so we might need something simpler for them to manage.
Maybe if we let the users configure exactly the variables they need, they could go around the issues until the fix lands into stable.
Sure yeah, this was a relatively recent bug fix so you'll want to grab the adapter from here. For your use case you'll want the *.reactor.wasm
one (link). Next you'll add this to the Cargo.toml
in the project that's built with cargo component
:
[package.metadata.component]
adapter = "path/to/wasi_snapshot_preview1.reactor.wasm"
Then cargo component build
will pick up that adapter and use it which should have the fix. The built-in one to cargo-component can also be updated soon too.
Thanks @alexcrichton, this solved my test issues.
Test Case
So, this is pretty weird, and kind of hard to reproduce... But I was able to get my wasm component to panic with a simple call in the guest:
The host has wasm component model enabled, async support is on and so is fuel consumption. Enabled WASI calls:
In addition,
Steps to Reproduce
Expected Results
Test would fail normally or at least not panic in guest.
Actual Results
The guest panics on
std::env::var
call:Versions and Environment
Wasmtime version or commit: 21.0.1
Operating system: NixOS unstable
Architecture: x86-64 and wasm32-wasi for the guest