Stream: git-wasmtime

Topic: wasmtime / Issue #2642 Path existence doesn't work correc...

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2021 at 03:04):

RReverser opened Issue #2642:

Compile this minimal repro sample to WASI:

fn main() -> std::io::Result<()> {
    let path = std::path::Path::new("dir.tmp");
    std::fs::create_dir(path)?;
    assert!(path.exists());
    Ok(())
}

and execute with wasmtime --dir . on Windows.

It successfully creates the directory, but the path.exists() assertion fails.

This error does not reproduce either on Linux (with the same binary) or with Wasmer, so it seems to be an OS-specific Wasmtime bug.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2021 at 03:04):

RReverser labeled Issue #2642:

Compile this minimal repro sample to WASI:

fn main() -> std::io::Result<()> {
    let path = std::path::Path::new("dir.tmp");
    std::fs::create_dir(path)?;
    assert!(path.exists());
    Ok(())
}

and execute with wasmtime --dir . on Windows.

It successfully creates the directory, but the path.exists() assertion fails.

This error does not reproduce either on Linux (with the same binary) or with Wasmer, so it seems to be an OS-specific Wasmtime bug.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2021 at 11:19):

tschneidereit assigned Issue #2642:

Compile this minimal repro sample to WASI:

fn main() -> std::io::Result<()> {
    let path = std::path::Path::new("dir.tmp");
    std::fs::create_dir(path)?;
    assert!(path.exists());
    Ok(())
}

and execute with wasmtime --dir . on Windows.

It successfully creates the directory, but the path.exists() assertion fails.

This error does not reproduce either on Linux (with the same binary) or with Wasmer, so it seems to be an OS-specific Wasmtime bug.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 06 2021 at 11:19):

tschneidereit commented on Issue #2642:

cc @pchickey

view this post on Zulip Wasmtime GitHub notifications bot (Feb 09 2021 at 20:15):

pchickey commented on Issue #2642:

I was able to reproduce this by having --dir . point to a network share drive (which in turn is a virtualbox shared folder) on windows, it succeeds if the directory is on the c: drive. Does that match your setup @RReverser ?

view this post on Zulip Wasmtime GitHub notifications bot (Feb 09 2021 at 20:23):

RReverser commented on Issue #2642:

No, it was a regular folder for me.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 09 2021 at 20:27):

RReverser commented on Issue #2642:

A simplified example on a different machine, just using a normal dir:

PS C:\src\temp> cat temp.rs
fn main() -> std::io::Result<()> {
        let path = std::path::Path::new("somefolder");
        assert!(path.exists());
        Ok(())
}
PS C:\src\temp> rustc temp.rs --target wasm32-wasi -o temp.wasm -O
PS C:\src\temp> mkdir somefolder

    Directory: C:\src\temp

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----          09/02/2021    20:26                somefolder

PS C:\src\temp> wasmtime temp.wasm --dir .
thread 'main' panicked at 'assertion failed: path.exists()', temp.rs:3:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: failed to run main module `temp.wasm`

Caused by:
    0: failed to invoke command default
    1: wasm trap: unreachable
       wasm backtrace:
           0: 0x732c - <unknown>!__rust_start_panic
           1: 0x6fd7 - <unknown>!rust_panic
           2: 0x6c4d - <unknown>!std::panicking::rust_panic_with_hook::h072472ae3822b936
           3:  0x733 - <unknown>!std::panicking::begin_panic::{{closure}}::hfed4ec7863cc1289
           4:  0x6fa - <unknown>!std::sys_common::backtrace::__rust_end_short_backtrace::hfec2f5ffa151ce3e
           5:  0x5b4 - <unknown>!std::panicking::begin_panic::h149d16135664954e
           6:  0x673 - <unknown>!temp::main::h842f3f6f3b24d55a
           7:  0x754 - <unknown>!std::sys_common::backtrace::__rust_begin_short_backtrace::hf584982b1a42bf23
           8:  0x51b - <unknown>!std::rt::lang_start::{{closure}}::hc3a5cf2a7641d397
           9: 0x70e8 - <unknown>!std::rt::lang_start_internal::ha925d42982681c99
          10:  0x6aa - <unknown>!__original_main
          11:  0x3cd - <unknown>!_start
       note: run with `WASMTIME_BACKTRACE_DETAILS=1` environment variable to display more information

view this post on Zulip Wasmtime GitHub notifications bot (Feb 09 2021 at 20:29):

RReverser edited a comment on Issue #2642:

A simplified example on a different machine, just using a normal dir:

PS C:\src\temp> cat temp.rs
fn main() -> std::io::Result<()> {
        let path = std::path::Path::new("somefolder");
        assert!(path.exists());
        Ok(())
}
PS C:\src\temp> rustc temp.rs --target wasm32-wasi -o temp.wasm -O
PS C:\src\temp> mkdir somefolder

    Directory: C:\src\temp

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----          09/02/2021    20:26                somefolder

PS C:\src\temp> wasmtime temp.wasm --dir .
thread 'main' panicked at 'assertion failed: path.exists()', temp.rs:3:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: failed to run main module `temp.wasm`

Caused by:
    0: failed to invoke command default
    1: wasm trap: unreachable
       wasm backtrace:
           0: 0x732c - <unknown>!__rust_start_panic
           1: 0x6fd7 - <unknown>!rust_panic
           2: 0x6c4d - <unknown>!std::panicking::rust_panic_with_hook::h072472ae3822b936
           3:  0x733 - <unknown>!std::panicking::begin_panic::{{closure}}::hfed4ec7863cc1289
           4:  0x6fa - <unknown>!std::sys_common::backtrace::__rust_end_short_backtrace::hfec2f5ffa151ce3e
           5:  0x5b4 - <unknown>!std::panicking::begin_panic::h149d16135664954e
           6:  0x673 - <unknown>!temp::main::h842f3f6f3b24d55a
           7:  0x754 - <unknown>!std::sys_common::backtrace::__rust_begin_short_backtrace::hf584982b1a42bf23
           8:  0x51b - <unknown>!std::rt::lang_start::{{closure}}::hc3a5cf2a7641d397
           9: 0x70e8 - <unknown>!std::rt::lang_start_internal::ha925d42982681c99
          10:  0x6aa - <unknown>!__original_main
          11:  0x3cd - <unknown>!_start
       note: run with `WASMTIME_BACKTRACE_DETAILS=1` environment variable to display more information
PS C:\src\temp> wasmer temp.wasm --dir .
PS C:\src\temp>

view this post on Zulip Wasmtime GitHub notifications bot (Feb 09 2021 at 20:45):

pchickey commented on Issue #2642:

With that smaller example I have the same behavior as before - passes when running on c:, fails when running on z:. I'll see if I can get a colleague to reproduce it.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 09 2021 at 20:47):

pchickey edited a comment on Issue #2642:

With that smaller example I have the same behavior as before - passes when running on c:, fails when running on z:. I'll see if I can get a colleague to reproduce it.

I am running wasmtime ab811d7445b3cf19640b97ca45372a0987da81c5 built in debug mode

view this post on Zulip Wasmtime GitHub notifications bot (Feb 09 2021 at 22:42):

peterhuene commented on Issue #2642:

If I use 40c4c6ac9bde95c72666d0cafb2ede6c7045edf9, I get the same behavior as @RReverser when somefolder is a directory and not a file.

It looks like path_filestat_get with the directory results in EACCES:

 DEBUG wasi_common::wasi                              > Error: Acces
 TRACE wasi_common::wasi::wasi_snapshot_preview1      > error=Ok(Acces)

When it's a file, the path_filestat_get call succeeds and there's no panic from the assert.

With e4827ad779c8adf5d99d9b1a1aa62f07af78c892, the repro succeeds with both a directory and file provided the CWD is not a mapped drive.

When it is a mapped drive, it appears we're messing around with path prefixes with strip_extended_prefix to remove \\?\ which results in out_path being UNC\\<path>\\somefolder rather than \\?\UNC\<path>\\somefolder, which results in a ENOENT error for the path as there's no relative UNC directory.

Thus mapped drives don't work at all for files or directories.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 09 2021 at 23:02):

peterhuene commented on Issue #2642:

I should note that the problem I noticed with the weird UNC path was before the cap-std change was merged, but I suspect something similar is going on such that \\?\ prefixed paths are breaking WASI.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 09 2021 at 23:15):

peterhuene commented on Issue #2642:

Indeed, the same prefix-stripping code is in cap-primitives: https://github.com/bytecodealliance/cap-std/blob/main/cap-primitives/src/windows/fs/get_path.rs

view this post on Zulip Wasmtime GitHub notifications bot (Feb 09 2021 at 23:16):

peterhuene edited a comment on Issue #2642:

I should note that the problem I noticed with the weird UNC path was before the cap-std change was merged, but I suspect something similar is going on such that \\?\ prefixed paths are breaking cap-std.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 09 2021 at 23:18):

RReverser commented on Issue #2642:

With e4827ad, the repro succeeds with both a directory and file provided the CWD is not a mapped drive.

Ah, so it's fixed on the main branch, just not in the latest release?

view this post on Zulip Wasmtime GitHub notifications bot (Feb 09 2021 at 23:20):

peterhuene commented on Issue #2642:

With the exception of UNC paths, I believe so.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 09 2021 at 23:21):

RReverser commented on Issue #2642:

Heh, in that case perfect timing for the issue on my side - just the day after it was fixed :sweat_smile:

view this post on Zulip Wasmtime GitHub notifications bot (Feb 09 2021 at 23:51):

pchickey commented on Issue #2642:

Thanks for reporting this and for bearing with us while we whittled down two independent problems. I've made a new issue to track the UNC paths problems, and will close this issue.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 09 2021 at 23:51):

pchickey closed Issue #2642 (assigned to pchickey):

Compile this minimal repro sample to WASI:

fn main() -> std::io::Result<()> {
    let path = std::path::Path::new("dir.tmp");
    std::fs::create_dir(path)?;
    assert!(path.exists());
    Ok(())
}

and execute with wasmtime --dir . on Windows.

It successfully creates the directory, but the path.exists() assertion fails.

This error does not reproduce either on Linux (with the same binary) or with Wasmer, so it seems to be an OS-specific Wasmtime bug.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 10 2021 at 19:41):

RReverser commented on Issue #2642:

@pchickey Do you happen to have a date of the next release? It's not super-urgent, just a bit annoying issue to deal with.

Last updated: Nov 22 2024 at 17:03 UTC