-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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-common: cannot use file handles for WasiCtxBuilder::std[in|out|err]
#1735
Comments
A regression in bytecodealliance#1561 caused "invalid argument" errors when `stdin`, `stdout`, and `stderr` are given a file handle. This was missed in Wasmtime CI because previously only a pipe handle was being used. It was caught in the .NET implementation CI because it uses file handles for its WASI tests. Fixes bytecodealliance#1735.
Oh shoot, it seems that my refactoring regressed a lot more than expected, sorry about that! I’ll have a look ASAP and also will try figure out an additional test. Thanks for the report @peterhuene! |
Just out of curiosity, would #1600 fix this issue for you? |
From a quick glance, I don't think it would, as the .NET API goes through the WASI C API, which remains using I was thinking of a more specific fix to where we currently handle |
Breaking change to the Rust API aside, I think if we changed those to |
A regression in bytecodealliance#1561 caused "invalid argument" errors when `stdin`, `stdout`, and `stderr` are given a file handle. This was missed in Wasmtime CI because previously only a pipe handle was being used. It was caught in the .NET implementation CI because it uses file handles for its WASI tests. Fixes bytecodealliance#1735.
Since #1600 landed, I’m closing this one. Feel free to reopen it though if you feel it’s not been fully fixed @peterhuene! |
It appears that #1561 regressed
WasiCtxBuilder::stdin
,WasiCtxBuilder::stdout
, andWasiCtxBuilder::stderr
because it is usingOsOther
which will error with invalid argument when given a file handle.cc @kubkon.
This caused a CI failure in the .NET implementation that I hadn't had time to look into the last few days.
Unfortunately, there's a test coverage hole in Wasmtime CI where only a pipe handle was used for these functions, which is why the regression wasn't caught (
OsOther
works fine for pipes).The text was updated successfully, but these errors were encountered: