Stream: git-wasmtime

Topic: wasmtime / issue #10058 wasmtime-wasi only preopening the...

Wasmtime GitHub notifications bot (Jan 21 2025 at 08:29):

justingaffney added the bug label to Issue #10058.

Wasmtime GitHub notifications bot (Jan 21 2025 at 08:29):

justingaffney opened issue #10058:

Test Case

Clone example repo here: https://github.com/justingaffney/wasmtime-preopen-bug

Steps to Reproduce

• Build component
  * cd component
  * cargo component build --release
• Run host
  * cd ..
  * cargo run

Expected Results

The following output:

Reading /a: Success
Reading /b: Success
Reading /c: Success
Reading /d: Success
Reading /e: Success

Actual Results

The following output:

Reading /a: Success
Reading /b: Failed. Error: Some(Custom { kind: Uncategorized, error: "failed to find a pre-opened file descriptor through which \"/b\" could be opened" })
Reading /c: Failed. Error: Some(Custom { kind: Uncategorized, error: "failed to find a pre-opened file descriptor through which \"/c\" could be opened" })
Reading /d: Failed. Error: Some(Custom { kind: Uncategorized, error: "failed to find a pre-opened file descriptor through which \"/d\" could be opened" })
Reading /e: Success

Versions and Environment

Wasmtime version or commit: 28.0.1, 29.0.0

Operating system: Windows 11

Architecture: x86_64

Wasmtime GitHub notifications bot (Jan 21 2025 at 09:01):

justingaffney commented on issue #10058:

I just tried it on Ubuntu 24.04.1 and have the same issue

Wasmtime GitHub notifications bot (Jan 21 2025 at 17:40):

alexcrichton commented on issue #10058:

Thanks for the report! This should be fixed in https://github.com/bytecodealliance/wasmtime/pull/10064. I'll note though that this is a bug in the "adapter" which will take a bit of time to propagate to toolchains. In the meantime working around this will be difficult as the adapter is pretty deep inside tooling and difficult to update-on-a-dime.

Wasmtime GitHub notifications bot (Jan 21 2025 at 18:30):

alexcrichton closed issue #10058:

Test Case

Clone example repo here: https://github.com/justingaffney/wasmtime-preopen-bug

Steps to Reproduce

• Build component
  * cd component
  * cargo component build --release
• Run host
  * cd ..
  * cargo run

Expected Results

The following output:

Reading /a: Success
Reading /b: Success
Reading /c: Success
Reading /d: Success
Reading /e: Success

Actual Results

The following output:

Reading /a: Success
Reading /b: Failed. Error: Some(Custom { kind: Uncategorized, error: "failed to find a pre-opened file descriptor through which \"/b\" could be opened" })
Reading /c: Failed. Error: Some(Custom { kind: Uncategorized, error: "failed to find a pre-opened file descriptor through which \"/c\" could be opened" })
Reading /d: Failed. Error: Some(Custom { kind: Uncategorized, error: "failed to find a pre-opened file descriptor through which \"/d\" could be opened" })
Reading /e: Success

Versions and Environment

Wasmtime version or commit: 28.0.1, 29.0.0

Operating system: Windows 11

Architecture: x86_64

Wasmtime GitHub notifications bot (Jan 22 2025 at 08:20):

justingaffney commented on issue #10058:

Thanks for the fast response!

It looks like the adapter is used in quite a few places, and I'm not sure how it all fits together yet. In the case of my example repo would I just need the next release of cargo-component, that contains your merged PR updating wasi-preview1-component-adapter-provider? Then I'd just need to run cargo component build again to include the new adapter version in the produced .wasm file?

Wasmtime GitHub notifications bot (Jan 22 2025 at 17:04):

alexcrichton commented on issue #10058:

I believe that should work yeah!

Last updated: Jan 24 2025 at 00:11 UTC