Wasmtime GitHub notifications bot (May 07 2023 at 17:56): Wasmtime GitHub notifications bot (May 07 2023 at 17:56):yowl opened issue #6352:
Test Case
Create a wasm which as a main that exits with a return value > 1. E.g. the attached
Steps to Reproduce
- wasmtime --wasm-features=threads --wasi-modules=experimental-wasi-threads HelloWasm.wasm
- echo %ERROR_LEVEL%
Expected Results
should print 100
Actual Results
prints 1
Versions and Environment
Wasmtime version or commit: wasmtime-cli 9.0.0
Operating system: Win11
Architecture: x64
Extra Info
Node.js prints 100 for this test. Thanks!
Wasmtime GitHub notifications bot (May 07 2023 at 17:56):yowl labeled issue #6352:
Test Case
Create a wasm which as a main that exits with a return value > 1. E.g. the attached
Steps to Reproduce
- wasmtime --wasm-features=threads --wasi-modules=experimental-wasi-threads HelloWasm.wasm
- echo %ERROR_LEVEL%
Expected Results
should print 100
Actual Results
prints 1
Versions and Environment
Wasmtime version or commit: wasmtime-cli 9.0.0
Operating system: Win11
Architecture: x64
Extra Info
Node.js prints 100 for this test. Thanks!
Wasmtime GitHub notifications bot (May 07 2023 at 18:04):sunfishcode commented on issue #6352:
On Windows, error codes have a different meaning than on Unix. Error code 100 on Windows means "Cannot create another system semaphore", which wouldn't correctly reflect the intent of a portable program, so Wasmtime normalizes error codes.
Wasmtime GitHub notifications bot (May 07 2023 at 18:08):yowl commented on issue #6352:
I see, this it the how the dotnet runtime tests work so would have thought they would be ok. Note that node.js behaves in line with how these tests are run. However if it is not consider wrong, then I can take it up with the dotnet team and perhaps change the how the test results are analysed.
Wasmtime GitHub notifications bot (May 07 2023 at 18:09):yowl commented on issue #6352:
Wasmtime GitHub notifications bot (May 07 2023 at 18:40):sunfishcode commented on issue #6352:
There is some design tension here. On one hand there's a desire to have WASI programs be portable and avoid having assumptions about how they're being used. On the other hand, this dotnet example shows an example of programs that know how they're going to be used and have a special convention that only has meaning in that context.
We could potentially relax this, within some limits (Unix has more restrictions on the value). Perhaps one question is, how much of a need is there for real-world programs to use custom error code conventions, rather than just specialized situations like test harnesses?
Wasmtime GitHub notifications bot (May 07 2023 at 19:02):bjorn3 commented on issue #6352:
Rust uses 101 for panics. ls uses 1 for minor issues and 2 for major issues. Tar uses 1 for when some files differ in comparison mode and uses 2 for fatal errors.
Wasmtime GitHub notifications bot (May 07 2023 at 19:03):bjorn3 edited a comment on issue #6352:
Rust uses 101 for panics.
lsuses 1 for minor issues and 2 for major issues.taruses 1 for when some files differ in comparison mode and uses 2 for fatal errors.
Wasmtime GitHub notifications bot (May 07 2023 at 22:23):yowl commented on issue #6352:
Error code 100 on Windows means
These are the code for
GetLastError, i.e. calls to the Win32 API, which is not the same as the main return value. Interestingly it looks like *nix has more restrictions, yet wasmtime does indeed return the main exit code there (e.g. with$?in bash)
Wasmtime GitHub notifications bot (May 07 2023 at 22:58):yowl commented on issue #6352:
Some more investigation,
wasmeron linux and windows shows 100 for the exit code. Out of the 4 that I've tried the odd one out so far is wasmtime on windows.
Wasmtime GitHub notifications bot (May 08 2023 at 01:48):sunfishcode commented on issue #6352:
These are the code for GetLastError, i.e. calls to the Win32 API, which is not the same as the main return value.
There are programs which return the
GetLastErroras their exit status, though it appears this convention is not as widespread as I initially thought.Wasmtime is starting to anticipate WASI Preview2 in some parts of its implementation, and Preview2 currently has only a boolean success-or-failure exit status from commands. I've now filed https://github.com/WebAssembly/wasi-cli/issues/11 to discuss expanding it.
Wasmtime GitHub notifications bot (May 08 2023 at 13:10):yowl commented on issue #6352:
Thanks, @sunfishcode do you want to close this then and it can just be taken up in https://github.com/WebAssembly/wasi-cli/issues/11 ? That would be fine with me.
Wasmtime GitHub notifications bot (May 08 2023 at 17:15):abrown commented on issue #6352:
Yeah, seems like we should have one issue for this: I also had https://github.com/WebAssembly/WASI/issues/524 open which I believe is similar.
Wasmtime GitHub notifications bot (May 08 2023 at 17:16):yowl closed issue #6352:
Test Case
Create a wasm which as a main that exits with a return value > 1. E.g. the attached
Steps to Reproduce
- wasmtime --wasm-features=threads --wasi-modules=experimental-wasi-threads HelloWasm.wasm
- echo %ERROR_LEVEL%
Expected Results
should print 100
Actual Results
prints 1
Versions and Environment
Wasmtime version or commit: wasmtime-cli 9.0.0
Operating system: Win11
Architecture: x64
Extra Info
Node.js prints 100 for this test. Thanks!
Last updated: Oct 23 2024 at 20:03 UTC