Skip to content
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

Change proc_exit to unwind the stack rather than exiting the host process. #1646

Merged

Conversation

sunfishcode
Copy link
Member

This allows programs which call proc_exit to coexist with other programs in the same host process. This also implements the semantics in WebAssembly/WASI#235.

Fixes #783.
Fixes #993.

@github-actions github-actions bot added cranelift Issues related to the Cranelift code generator wasi Issues pertaining to WASI wasmtime:api Related to the API of the `wasmtime` crate itself labels May 1, 2020
@github-actions
Copy link

github-actions bot commented May 1, 2020

Subscribe to Label Action

cc @bnjbvr, @kubkon, @peterhuene

This issue or pull request has been labeled: "cranelift", "wasi", "wasmtime:api"

Thus the following users have been cc'd because of the following labels:

  • bnjbvr: cranelift
  • kubkon: wasi
  • peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

crates/wiggle/generate/src/funcs.rs Outdated Show resolved Hide resolved
Copy link
Member

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would personally prefer to keep imported functions having the signature Result<T, Trap> instead of anyhow::Error as the error payload. That feels more closely aligned with the wasm spec and avoids us having weird questions about how to interpret various kinds of errors from imported functions. (to me it feels pretty straightforward that returning any sort of "trap" results in a wasm trap immediately)

Could this instead be extended to avoid special-casing on proc_exit and changing the error type? Perhaps Trap could have a new constructor representing "wasm exited" or something like that? Basically I'm thinking we could soup up the Trap type to have more information inside it, and one of the variants of information is "the program requested an exit". That way the trap could propagate all the way up to the wasmtime CLI, which could catch the error, and then exit the process accordingly. The worst-case scenario would be handling the trap as a usual wasm trap, which typically results in killing the wasm anyway right now.

crates/api/src/func.rs Outdated Show resolved Hide resolved
crates/runtime/src/traphandlers.rs Outdated Show resolved Hide resolved
crates/runtime/src/traphandlers.rs Outdated Show resolved Hide resolved
@sunfishcode
Copy link
Member Author

Thanks for the feedback @pchickey and @alexcrichton! I've now reworked the patch here to avoid making any changes to wiggle, and to go back to Result<T, Trap> with extra info in Trap instead of anyhow::Error. Both of these turned out to enable several things to be much simpler as well.

@github-actions github-actions bot added the wasmtime:c-api Issues pertaining to the C API. label May 12, 2020
@github-actions
Copy link

Subscribe to Label Action

cc @peterhuene

This issue or pull request has been labeled: "wasmtime:c-api"

Thus the following users have been cc'd because of the following labels:

  • peterhuene: wasmtime:c-api

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

Copy link
Member

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the spec testsuite change perhaps accidental?

crates/api/src/trap.rs Outdated Show resolved Hide resolved
// Print the error message in the usual way.
eprintln!("Error: {:?}", e);

if let TrapReason::I32Exit(status) = trap.reason() {
// On Windows, exit status 3 indicates an abort (see below),
// so just return 1 indicating a non-zero status.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems a bit odd to me, why not expose exiting with all sorts of error codes on Windows?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(or put another way I don't fully understand the comment as to why Windows is special here)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have a strong sense of what Windows wants here; I just didn't want to overload exit status 3 as meaning both "program trapped" and "program explicitly exited with status 3".

Am I reading too much into the docs by assuming that using 3 for an abort is a meaningful convention?

Copy link
Contributor

@pchickey pchickey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this approach looks much better

crates/wasi-common/src/snapshots/wasi_snapshot_preview1.rs Outdated Show resolved Hide resolved
@sunfishcode sunfishcode merged commit fb0b9e3 into bytecodealliance:master May 13, 2020
@sunfishcode sunfishcode deleted the sunfishcode/exit-unwind branch May 13, 2020 22:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cranelift Issues related to the Cranelift code generator wasi Issues pertaining to WASI wasmtime:api Related to the API of the `wasmtime` crate itself wasmtime:c-api Issues pertaining to the C API.
Projects
None yet
4 participants