Wasmtime does not exit with the same code as the wasm main on Windows

[yowl]

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!

HelloWasm.zip

[sunfishcode]

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.

[yowl]

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.

[yowl]

E.g. https://github.com/dotnet/runtimelab/blob/7fe97907a9a2f677e74f4a116363236c4966651c/src/tests/nativeaot/SmokeTests/UnitTests/Main.cs#L20

[sunfishcode]

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?

[bjorn3]

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.

[yowl]

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)

[yowl]

Some more investigation, wasmer on 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.

[sunfishcode]

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 GetLastError as 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 WebAssembly/wasi-cli#11 to discuss expanding it.

[yowl]

Thanks, @sunfishcode do you want to close this then and it can just be taken up in WebAssembly/wasi-cli#11 ? That would be fine with me.

[abrown]

Yeah, seems like we should have one issue for this: I also had WebAssembly/WASI#524 open which I believe is similar.