Stream: git-wasmtime

Topic: wasmtime / issue #6352 Wasmtime does not exit with the sa...


view this post on Zulip 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

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

view this post on Zulip 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

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

view this post on Zulip 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.

view this post on Zulip 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.

view this post on Zulip Wasmtime GitHub notifications bot (May 07 2023 at 18:09):

yowl commented on issue #6352:

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

view this post on Zulip 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?

view this post on Zulip 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.

view this post on Zulip Wasmtime GitHub notifications bot (May 07 2023 at 19:03):

bjorn3 edited a comment 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.

view this post on Zulip 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)

view this post on Zulip Wasmtime GitHub notifications bot (May 07 2023 at 22:58):

yowl commented on issue #6352:

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.

view this post on Zulip 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 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 https://github.com/WebAssembly/wasi-cli/issues/11 to discuss expanding it.

view this post on Zulip 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.

view this post on Zulip 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.

view this post on Zulip 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

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


Last updated: Dec 23 2024 at 13:07 UTC