Skip to content

wasmtime-wasi only preopening the first and last directory set in WasiCtxBuilder #10058

Closed

Description

@justingaffney

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

Activity

  1. added
    bugIncorrect behavior in the current implementation that needs fixing
    on Jan 21, 2025
  2. justingaffney commented on Jan 21, 2025

    @justingaffney
    Author

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

  3. added a commit that references this issue on Jan 21, 2025
    d3afa6d
  4. alexcrichton commented on Jan 21, 2025

    @alexcrichton
    Member

    Thanks for the report! This should be fixed in #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.

  5. added a commit that references this issue on Jan 21, 2025
    7ba0347
  6. added 4 commits that reference this issue on Jan 21, 2025
    ce4a5eb
    e304726
    67eb350
    93dd0eb
  7. added a commit that references this issue on Jan 21, 2025
  8. added 2 commits that reference this issue on Jan 22, 2025
  9. justingaffney commented on Jan 22, 2025

    @justingaffney
    Author

    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?

  10. alexcrichton commented on Jan 22, 2025

    @alexcrichton
    Member

    I believe that should work yeah!

  11. added a commit that references this issue on Jan 22, 2025
  12. added a commit that references this issue on Jan 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugIncorrect behavior in the current implementation that needs fixing

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions