KernelErr labeled issue #3660:
Test Case
Compiled RustPython.
Steps to Reproduce
Input any wrong python syntax like:
Expected Results
There should be a Python error pointing out a syntax error.
Actual Results
Syntax errors could not be printed out in time.
Versions and Environment
Wasmtime version or commit: 0.33.0
Operating system: Linux
Architecture: amd64
Extra Info
On other runtimes, there could be current output.
KernelErr opened issue #3660:
Test Case
Compiled RustPython.
Steps to Reproduce
Input any wrong python syntax like:
Expected Results
There should be a Python error pointing out a syntax error.
Actual Results
Syntax errors could not be printed out in time.
Versions and Environment
Wasmtime version or commit: 0.33.0
Operating system: Linux
Architecture: amd64
Extra Info
On other runtimes, there could be current output.
KernelErr edited issue #3660:
Test Case
Compiled RustPython.
Steps to Reproduce
Input any wrong python syntax like:
Expected Results
There should be a syntax error right after the wrong line.
Actual Results
Syntax errors could not be printed out in time.
Versions and Environment
Wasmtime version or commit: 0.33.0
Operating system: Linux
Architecture: amd64
Extra Info
On other runtimes, there could be correct output.
alexcrichton commented on issue #3660:
Thanks for the report, are you able to share the source for how this module was built? Testing locally it appears that Wasmtime is doing the right thing with respect to the WASI API calls made. It may be a difference in WASI behavior between runtimes, though, causing this issue.
KernelErr commented on issue #3660:
Hi, I am using code from RustPython's pr 3514(https://github.com/RustPython/RustPython/pull/3514). That's because I opened issue 3513 for it.
After cloning the RustPython repo, I used GitHub CLI to checkout the pr and ran the following command to build:
cargo build --release --target wasm32-wasi --features="freeze-stdlib"
I built it again, and the problem still exists.
alexcrichton commented on issue #3660:
cc @sunfishcode and @pchickey, this all boils down to
isatty({0,1,2})
which is a mixture of:
isatty
in wasi-libc- default rights for stdio in wasi-common set to
::all()
- stdio types having an
Unknown
file typeIt looks like the
rustpython.wasm
is differing its behavior based on whether the stdin/stdout/stderr are a tty, and that basically affects buffering which means that the error being expected here is buffered to be printed later. The test forisatty
inwasi-libc
needs two modifications inwasi-common
to clear checks, one being changingUnknown
to something not-unknown, and another being removing rights from the stdio descriptors.I don't really know where the bug here is. A lot of this is basically legacy I think and there's not really a crisp-and-clear definition of what everything should be. There's not really a bug in Wasmtime per-se, it's just that our stdio descriptors don't look like something that rustpython is expecting and as a result rustpython behaves oddly.
alexcrichton commented on issue #3660:
I think this was fixed in https://github.com/bytecodealliance/wasmtime/pull/3696, so closing.
alexcrichton closed issue #3660:
Test Case
Compiled RustPython.
Steps to Reproduce
Input any wrong python syntax like:
Expected Results
There should be a syntax error right after the wrong line.
Actual Results
Syntax errors could not be printed out in time.
Versions and Environment
Wasmtime version or commit: 0.33.0
Operating system: Linux
Architecture: amd64
Extra Info
On other runtimes, there could be correct output.
Last updated: Dec 23 2024 at 12:05 UTC