Stack overflow when calling std::terminate + -fwasm-exceptions
#16407
Assignees
Comments
aheejin
added a commit
to aheejin/emscripten
that referenced
this issue
May 7, 2022
We used to implement `abort()` with throwing a JS exception. emscripten-core#9730 changed it to `RuntimeError`, because it is the class a trap becomes once it hits a JS frame. But this turned out to be not working, because Wasm EH currently does not assume all `RuntimeError`s are from traps; it decides whether a `RuntimeError` is from a trap or not based on a hidden field within the object. Relevant past discussion: WebAssembly/exception-handling#89 (comment) So at the moment we don't have a way of throwing a trap from JS, which is inconvenient. I think we eventually want to make JS API for this, but for the moment, this PR resorts to a wasm function that traps. This at least makes calling `std::terminate` work. So far calling it exhausted the call stack and aborted. Fixes emscripten-core#16407.
aheejin
added a commit
to aheejin/emscripten
that referenced
this issue
May 7, 2022
We used to implement `abort()` with throwing a JS exception. emscripten-core#9730 changed it to `RuntimeError`, because it is the class a trap becomes once it hits a JS frame. But this turned out to be not working, because Wasm EH currently does not assume all `RuntimeError`s are from traps; it decides whether a `RuntimeError` is from a trap or not based on a hidden field within the object. Relevant past discussion: WebAssembly/exception-handling#89 (comment) So at the moment we don't have a way of throwing a trap from JS, which is inconvenient. I think we eventually want to make JS API for this, but for the moment, this PR resorts to a wasm function that traps. This at least makes calling `std::terminate` work. So far calling it exhausted the call stack and aborted. Fixes emscripten-core#16407.
aheejin
added a commit
to aheejin/emscripten
that referenced
this issue
May 10, 2022
`noexcept` function shouldn't throw, so `noexcept` function code generation is to `invoke` every function call in those functions and in case they throw, call `std::terminate`. This codegen comes from clang and native platforms do this too. So in wasm, they become something like ```wasm try function body catch_all call std::terminate end ``` `std::terminate` calls `std::__terminate`. Both of `std::terminate` and `std::__terminate` are `noexcept` now. So that means their code is structured like that, which sounds like self-calling, but normally no function calls in those functions should ever throw, so that's fine. But in our case, `abort` ends up throwing, which is a problem. The function body of `__terminate` eventually calls JS `abort`, and ends up here: https://github.com/emscripten-core/emscripten/blob/970998b2670a9bcf39d31e2b01db571089955add/src/preamble.js#L605-L623 This ends up throwing a JS exception. This is basically just a foreign exception from the wasm perspective, and is caught by `catch_all`, and calls `std::terminate` again. And the whole process continues until the call stack is exhausted. What emscripten-core#9730 tried to do was throwing a trap, because Wasm `catch`/`catch_all` don't catch traps. Traps become `RuntimeError`s after they hit a JS frame. To be consistent, we decided `catch`/`catch_all` shouldn't catch them after they become `RuntimeError`s. That's the reason emscripten-core#9730 changed the code to throw not just any random thing but `RuntimeError`. But somehow we decided that we make that trap distinction not based on `RuntimeError` class but some hidden field (WebAssembly/exception-handling#89 (comment)). This PR removes `noexcept` from `std::terminate` and `std::__terminate`'s signatures so that the cleanup that contains `catch_all` is not generated for those two functions. So now the JS exception thrown by `abort()` will unwind the stack, which is different from native, but that can be considered OK because I don't think users expect `abort` to preserve the stack intact? Fixes emscripten-core#16407.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The following code when compiled with
-fwasm-exceptionscauses a stack overflow when executed:Version of emscripten/emsdk:
Failing command line in full:
This is the end of the program's output:
Full link command and output with
-vappended:The text was updated successfully, but these errors were encountered: