[EH] Make Wasm EH rethrow print stack traces #20372

aheejin · 2023-10-02T20:55:08Z

In Wasm EH, even if we set -sASSERTION or -sEXCEPTION_STACK_TRACES, if we rethrow an exception in the code, we lose the effect of that option because previously we called __throw_exception_with_stack_trace only in __cxa_throw:

emscripten/system/lib/libcxxabi/src/cxa_exception.cpp

Lines 294 to 296 in 9ce7020

    
           // In debug mode, call a JS library function to use WebAssembly.Exception JS 
        
           // API, which enables us to include stack traces 
        
           __throw_exception_with_stack_trace(&exception_header->unwindHeader);

This adds the same mechanism to __cxa_rethrow (which is used for C++ throw;) and __cxa_rethrow_primary_exception (which is used for std::rethrow_exception).

This does not solve the problem of losing stack traces before the rethrowing. libc++abi's __cxa_rethrow and
__cxa_rethrow_primary_exception are implemented as throwing a pointer in the same way we first throw it and they are not aware of any metadata. This happens even in the native platform with GDB; GDB's backtrace only shows stack traces after rethrowing. We may try to fix this later by passing exnref
(WebAssembly/exception-handling#281) to the library, but this is likely to take some time.

Partially fixes #20301.

In Wasm EH, even if we set `-sASSERTION` or `-sEXCEPTION_STACK_TRACES`, if we rethrow an exception in the code, we lose the effect of that option because previously we called `__throw_exception_with_stack_trace` only in `__cxa_throw`: https://github.com/emscripten-core/emscripten/blob/9ce7020632aa6f7578c6e40e197b800a4dd7073f/system/lib/libcxxabi/src/cxa_exception.cpp#L294-L296 This adds the same mechanism to `__cxa_rethrow` (which is used for C++ `throw;`) and `__cxa_rethrow_primary_exception` (which is used for `std::rethrow_exception`). This does not solve the problem of losing stack traces _before_ the rethrowing. libc++abi's `__cxa_rethrow` and `__cxa_rethrow_primary_exception` are implemented as throwing a pointer in the same way we first throw it and they are not aware of any metadata. This happens even in the native platform with GDB; GDB's backtrace only shows stack traces after rethrowing. We may try to fix this later by passing `exnref` (WebAssembly/exception-handling#281) to the library, but this is likely to take some time. Partially fixes emscripten-core#20301.

sbc100 · 2023-10-02T20:59:10Z

system/lib/libcxxabi/src/cxa_exception.cpp

@@ -644,6 +644,14 @@ void __cxa_rethrow() {
    }
 #ifdef __USING_SJLJ_EXCEPTIONS__
    _Unwind_SjLj_RaiseException(&exception_header->unwindHeader);
+#elif __USING_WASM_EXCEPTIONS__


How about making this #elif defined(__USING_WASM_EXCEPTIONS__) && !defined(NDEBUG) to avoid inner if/else/endif?

How? We have

#else _Unwind_RaiseException(&exception_header->unwindHeader); #endif

at the end so I'm not sure how to rewrite this without an inner if...

I was thinking you could write this to avoid the duplication of the _Unwind_RaiseException(&exception_header->unwindHeader); block? And instead rely on the fall though to that else case?

Aha, sorry, I was confused and thought NDEBUG as the opposite... Simplified it, and also fixed the existing __cxa_throw part, which I copied this code from.

system/lib/libcxxabi/src/cxa_exception.cpp

sbc100 · 2023-10-02T21:00:43Z

system/lib/libcxxabi/src/cxa_exception.cpp

+#else
+    // In debug mode, call a JS library function to use WebAssembly.Exception JS
+    // API, which enables us to include stack traces
+    __throw_exception_with_stack_trace(&exception_header->unwindHeader);


This makes me wonder why _Unwind_RaiseException itself doesn't call __throw_exception_with_stack_trace under the hood? I'm sure there is a good reason..

I have a reason, even though am not sure how good that reason is... In native platforms libunwind is mostly used for very low level stack unwinding stuff, so I wanted to limit libunwind to low-level stuff as well, such as throwing exceptions using builtins. Interacting with JS seemed a too high level functionality for libunwind.

I guess it depends if we think there would be other callers of _Unwind_RaiseException that don't want __throw_exception_with_stack_trace ?

libunwind can be used by non-Emscripten toolchains, so there are others that don't want to call it. But that's gonna be the same for libc++abi... Maybe we should guard this part as not only __USING_WASM_EXCEPTIONS__ but also __EMSCRIPTEN__? Currently I haven't upstreamed any JS-related parts, including this, to upstream LLVM, so others will not be affected though.

Yes I think it makes sense to wrap this in __EMSCRIPTEN__. We can consider folding this into _Unwind_RaiseException itself, either as part of this PR, or as a followup.

Also, I don't see any harm in (eventually) upstreaming even the emscripten parts, assuming they are wrapped in #ifdef __EMSCRIPTEN__

sbc100 · 2023-10-02T21:01:41Z

test/test_other.py

@@ -8593,6 +8593,64 @@ def test_exceptions_stack_trace_and_message(self, wasm_eh):
    for check in stack_trace_checks:
      self.assertFalse(re.search(check, err), 'Expected regex "%s" to not match on:\n%s' % (check, err))

+    # Rethrowing exception currently loses the stack trace before the


Can this be a separate test? The existing test is already really long..

sbc100 · 2023-10-02T23:17:29Z

test/test_other.py

+      self.require_v8()
+      emcc_args += ['-fwasm-exceptions']
+    else:
+      emcc_args += ['-fexceptions']


You can self.emcc_args here and avoid passing this as emcc_args to the self.do_run calls below.

Ah, thanks. Fixed the same pattern in the original test_exceptions_stack_trace_and_message as well.

aheejin requested a review from sbc100 October 2, 2023 20:55

aheejin mentioned this pull request Oct 2, 2023

[EH] rethrowing current exception from catch lead to loss of callstack #20301

Closed

sbc100 reviewed Oct 2, 2023

View reviewed changes

system/lib/libcxxabi/src/cxa_exception.cpp Outdated Show resolved Hide resolved

sbc100 reviewed Oct 2, 2023

View reviewed changes

aheejin added 2 commits October 2, 2023 14:56

Address comments

a7c5fe5

Simplify if

d3f7e5b

sbc100 reviewed Oct 2, 2023

View reviewed changes

sbc100 approved these changes Oct 2, 2023

View reviewed changes

Use self.emcc_args

ca2da5c

sbc100 approved these changes Oct 3, 2023

View reviewed changes

aheejin merged commit 6b36901 into emscripten-core:main Oct 3, 2023
26 checks passed

aheejin deleted the rethrow_stack_trace branch October 3, 2023 22:19

aheejin mentioned this pull request Oct 4, 2023

[EH] Move call to __throw_exception_with_stack_trace to libunwind (NFC) #20389

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[EH] Make Wasm EH rethrow print stack traces #20372

[EH] Make Wasm EH rethrow print stack traces #20372

aheejin commented Oct 2, 2023

sbc100 Oct 2, 2023

aheejin Oct 2, 2023

sbc100 Oct 2, 2023

aheejin Oct 2, 2023

sbc100 Oct 2, 2023

aheejin Oct 2, 2023 •

edited

Loading

sbc100 Oct 2, 2023

aheejin Oct 2, 2023

sbc100 Oct 2, 2023

sbc100 Oct 2, 2023

sbc100 Oct 2, 2023

aheejin Oct 2, 2023

sbc100 Oct 2, 2023

aheejin Oct 3, 2023

	// In debug mode, call a JS library function to use WebAssembly.Exception JS
	// API, which enables us to include stack traces
	__throw_exception_with_stack_trace(&exception_header->unwindHeader);

[EH] Make Wasm EH rethrow print stack traces #20372

[EH] Make Wasm EH rethrow print stack traces #20372

Conversation

aheejin commented Oct 2, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aheejin Oct 2, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aheejin Oct 2, 2023 •

edited

Loading