Stream: general

Topic: Wasmtime exit code


view this post on Zulip Martin Torp (Nov 09 2020 at 09:35):

Wasmtime does not seem to accept exit codes greater than 125. Is their any reason for this limitation? I couldn't find any relevant documentation.
See wasi_proc_exit in https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasi/src/lib.rs

Standalone JIT-style runtime for WebAssembly, using Cranelift - bytecodealliance/wasmtime

view this post on Zulip Dan Gohman (Nov 09 2020 at 11:11):

in POSIX, exit codes >= 128 indicate that the process was terminated by a signal, and 126 and 127 are used to report errors launching child processes. WASI doesn't yet have signals or ways to launch child processes, and we're not yet sure what they'll look like, so we're erring on the side of being conservative

view this post on Zulip Dan Gohman (Nov 09 2020 at 11:12):

Do you have a use case which needs exit codes > 125?

view this post on Zulip Martin Torp (Nov 09 2020 at 11:20):

Thanks Dan. It does make sense.
I'm using the C API, and I would like to distinguish between a signal and a non-user trap. I don't think I'll need the exact signal, so I guess I can make the distinction from the trap message.

view this post on Zulip bjorn3 (Nov 09 2020 at 11:24):

WASI doesn't have signals.

view this post on Zulip bjorn3 (Nov 09 2020 at 11:27):

You can use wasmtime_trap_exit_status to determine if the trap was caused by a proc_exit or not.

Standalone JIT-style runtime for WebAssembly, using Cranelift - bytecodealliance/wasmtime

view this post on Zulip Martin Torp (Nov 09 2020 at 11:30):

bjorn3 said:

You can use wasmtime_trap_exit_status to determine if the trap was caused by a proc_exit or not.

Thanks Bjorn, that's what I'm doing ATM, but it returns false if the exit code is > 125. Even though WASI doesn't have signals, I still need to distinguish an exit code of [126, 255] from, e.g., an unreachable trap, but I guess I have to use the error message for that?

view this post on Zulip bjorn3 (Nov 09 2020 at 11:32):

When the exit code is in the range 126..=255, it isn't valid and you don't get an exit trap but an error trap.

view this post on Zulip bjorn3 (Nov 09 2020 at 11:32):

You must not pass 126..=255 to proc_exit.

view this post on Zulip Martin Torp (Nov 09 2020 at 11:34):

bjorn3 said:

You must not pass 126..=255 to proc_exit.

I'm not the one supplying the WASI binary. I'm just trying to handle the case where it happens.

view this post on Zulip bjorn3 (Nov 09 2020 at 11:35):

What application is it if I may ask?

view this post on Zulip Martin Torp (Nov 09 2020 at 11:37):

I'm writing a WebAssembly/WASI analysis and I'm using some more or less random C programs compiled with WASI-clang as benchmarks.

view this post on Zulip bjorn3 (Nov 09 2020 at 11:38):

Why would it return those strange exit codes?

view this post on Zulip Martin Torp (Nov 09 2020 at 11:39):

bjorn3 said:

Why would it return those strange exit codes?

return -1 seems to be a pretty common pattern for indicating a program failure.

view this post on Zulip Martin Torp (Nov 09 2020 at 11:39):

From the main function of course.

view this post on Zulip bjorn3 (Nov 09 2020 at 11:57):

On one hand POSIX seems to reserve EXIT_FAILURE as exit code for the purpose of calling exit on an error: https://pubs.opengroup.org/onlinepubs/9699919799/functions/exit.html, which is defined as 1 in wasi-libc: https://github.com/WebAssembly/wasi-libc/blob/575e1579a4ebaa6dccb884ca657188a92982af23/libc-top-half/musl/include/stdlib.h#L88 The C specification states that returning a value from the main function is equivalent to calling exit with the respective return value as argument: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf 5.1.2.2.3 Program termination

On the other hand POSIX does state that any value is allowed to be passed to exit: https://pubs.opengroup.org/onlinepubs/9699919799/functions/exit.html

WASI libc implementation for WebAssembly. Contribute to WebAssembly/wasi-libc development by creating an account on GitHub.

view this post on Zulip Jubilee (Nov 10 2020 at 06:32):

in practice, compliance with POSIX is very... handwavey.

view this post on Zulip Jubilee (Nov 10 2020 at 06:33):

which isn't even unexpected since in general it rarely specifies SHALL NOT, it only specifies SHALL and SHOULD, and in a way that allows a broad latitude of interpretation.

view this post on Zulip Jubilee (Nov 10 2020 at 06:35):

but like, my experience with experimenting with shells and the like which claim to be "POSIX-compliant" is that one should expect compliance with POSIX even on the points where it is clearly "do this" to be within a standard deviation, as it were, of interpretations.

view this post on Zulip Dan Gohman (Nov 10 2020 at 14:34):

I agree POSIX is handwavy in a lot of ways. So I think in this case, the question to ask is, if you could make exit(-1) do anything, what would you want it to do?

view this post on Zulip Dan Gohman (Nov 10 2020 at 14:34):

I don't know of any code that does exit(-1) myself, but apparently it happens

I see in a lot of legacy software and bad tutorials on the Internet that recommend using exit(-1), return -1 or similar to represent "abnormal termination". The problem is, in POSIX at least, -1 has

view this post on Zulip indolering (Nov 11 2020 at 02:37):

(deleted)


Last updated: Nov 22 2024 at 16:03 UTC