Skip to content
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

[WASI] Failed to find a pre-opened file descriptor #2079

Closed
XX opened this issue Jan 30, 2021 · 6 comments
Closed

[WASI] Failed to find a pre-opened file descriptor #2079

XX opened this issue Jan 30, 2021 · 6 comments
Assignees
Labels
bug Something isn't working priority-medium Medium priority issue
Milestone

Comments

@XX
Copy link
Contributor

XX commented Jan 30, 2021

I wrote a simple wasmer-wasi example that reads directory entries but it always fails.

wasi_fs_example/src/lib.rs:

#[no_mangle]
pub fn start() {
    std::fs::read_dir("/").unwrap();
}

runner/src/main.rs:

use wasmer::{Instance, Module, Store};
use wasmer_wasi::WasiState;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let wasm = std::fs::read("target/wasm32-wasi/debug/wasi_fs_example.wasm")?;

    let store = Store::default();
    let module = Module::new(&store, wasm)?;

    let mut wasi_env = WasiState::new("wasi_fs_example")
        .preopen_dir("target")?
        .finalize()?;

    let import_object = wasi_env.import_object(&module)?;
    let instance = Instance::new(&module, &import_object)?;

    let start = instance.exports.get_function("start")?;
    start.call(&[])?;

    Ok(())
}

This produce the error while running:

cargo build -p wasi_fs_example --target wasm32-wasi
cargo run -p runner
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: Other, error: "failed to find a pre-opened file descriptor through which \"/\" could be opened" }', wasi_fs_example/src/lib.rs:6:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Full source code of the example is located here. Why doesn't it work?

@XX XX added the bug Something isn't working label Jan 30, 2021
@XX
Copy link
Contributor Author

XX commented Jan 31, 2021

Currently in Rust we can really only create WASI binaries, not libraries. WASI only works for the duration of a main function that needs to be there. Calling the wasi functions from anywhere else segfaults because libpreopen isn't initialized.

So to summarize, how to fix this currently:

  • Do not have lib.crate-type at all
  • Have the file be src/main.rs, not src/lib.rs
  • Have #![no_main] at the top of the src/main.rs
  • Use RUSTFLAGS="-Z wasi-exec-model=reactor" cargo +nightly build --target wasm32-wasi
  • Make sure that you call _initialize before anything else

WebAssembly/WASI#24
rust-lang/rust#79997

@XX
Copy link
Contributor Author

XX commented Jan 31, 2021

In my case:

wasi_fs_example/src/main.rs:

#![no_main]

#[no_mangle]
pub extern "C" fn start() {
    std::fs::read_dir("/").unwrap();
}

runner/src/main.rs:

...
let start = instance.exports.get_function("_initialize")?;
start.call(&[])?;

let start = instance.exports.get_function("start")?;
start.call(&[])?;
...
RUSTFLAGS="-Z wasi-exec-model=reactor" cargo +nightly build -p wasi_fs_example --target wasm32-wasi

@MarkMcCaskey
Copy link
Contributor

MarkMcCaskey commented Feb 1, 2021

Interesting thanks for the info!

One thing I immediately noticed is the name of your start function. Wasmer CLI calls _start, not start. I'm not familiar with the Rust flags you're using to compile (RUSTFLAGS="-Z wasi-exec-model=reactor") but if it's not being set up correctly with initialize (as you point out) it won't work, so that's where I'd look first.

Edit: it wasn't clear to me upon first reading this issue but it seems like you've solved it! Is there are underlying issue here you'd still like resolved on wasmer's end?

@XX
Copy link
Contributor Author

XX commented Feb 3, 2021

@MarkMcCaskey Oh, consider that there is the name foo instead of start. It is a library, not a binary with _start and main. And for the library, WASI works correctly only with the #![no_main]/RUSTFLAGS="-Z wasi-exec-model=reactor" hack.

@XX XX closed this as completed Feb 3, 2021
@syrusakbary syrusakbary reopened this Nov 23, 2021
@syrusakbary syrusakbary added this to the v2.1 milestone Nov 23, 2021
@syrusakbary syrusakbary added the priority-medium Medium priority issue label Nov 23, 2021
@Amanieu Amanieu modified the milestones: v2.1, v2.x Nov 30, 2021
@epilys epilys modified the milestones: v2.x, v3.x, v3.0 Jun 21, 2022
@syrusakbary
Copy link
Member

We believe this issue was fixed by #2941. We need to create a test verifying this

@ptitSeb
Copy link
Contributor

ptitSeb commented Aug 3, 2022

After some fideling with the tests, I realized it's already there: wasi_sees_virtual_root.rs is exactly this test.
Ticket can be closed!

@ptitSeb ptitSeb closed this as completed Aug 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working priority-medium Medium priority issue
Projects
None yet
Development

No branches or pull requests

6 participants