-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
std::env::var from guest gives an error: cannot leave component instance #8835
Comments
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:
To be precise the adapter for |
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 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 [package.metadata.component]
adapter = "path/to/wasi_snapshot_preview1.reactor.wasm" Then |
Help to fix issues like bytecodealliance/wasmtime#8835 by fixing a bug in the adapter where over-large environment blocks could cause a panic.
Thanks @alexcrichton, this solved my test issues. |
Help to fix issues like bytecodealliance/wasmtime#8835 by fixing a bug in the adapter where over-large environment blocks could cause a panic.
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
The text was updated successfully, but these errors were encountered: