Crash with rethrow_exception and EXCEPTION_STACK_TRACES if first exception base class contains virtual methods

[stevenwdv]

A program crashes when using std::rethrow_exception(std::current_exception()) with Emscripten EXCEPTION_STACK_TRACES enabled if the exception has multiple base classes, one of which inherits from std::exception, if said base class is not the first one, and the actual first base class has virtual methods.

This only happens with -fwasm-exceptions, not with Emscripten -fexceptions.

This seems vaguely related to #6449, but it is closed. This issue only happens with std::rethrow_exception, not with throw;.

Steps to reproduce

• Create main.cpp with the following contents:

#include <iostream>
#include <exception>
#include <stdexcept>
#include <string>
#include <typeinfo>
#include <utility>

#include <cxxabi.h>

struct Virt {
	virtual void virt1() {}
#ifdef TWO_VIRTUAL
	virtual void virt2() {}
#endif
};

struct MyEx : Virt, public std::runtime_error {
	explicit MyEx(std::string msg) : std::runtime_error(std::move(msg)) {}
};

int main() {
	try {
		throw MyEx("ERROR");
	} catch (const std::exception &ex) {
		std::cerr << "__cxa_current_exception_type: " << abi::__cxa_current_exception_type()->name() << '\n';
		std::cerr << "typeid: " << typeid(ex).name() << '\n';
		std::cerr << "what: " << ex.what() << '\n';
		try {
			std::rethrow_exception(std::current_exception());
		} catch (const std::exception &ex) {
			std::cerr << "rethrow_exception __cxa_current_exception_type: " << abi::__cxa_current_exception_type()->name() << '\n';
			std::cerr << "rethrow_exception typeid: " << typeid(ex).name() << '\n';
			std::cerr << "rethrow_exception what: " << ex.what() << '\n';
		}
	}
}

• Now compile:

em++ -g -fwasm-exceptions main.cpp -o hello.js

• Now run the file (e.g. with Node.js, or use -o hello.html and open with a browser), and observe output:

$ node hello.js

__cxa_current_exception_type: 4MyEx
typeid: 4MyEx
what: ERROR
wasm://wasm/hello.wasm-00c67b12:1


RuntimeError: null function or function signature mismatch
    at hello.wasm.__get_exception_message (wasm://wasm/hello.wasm-00c67b12:wasm-function[2753]:0x40232)
    at /home/swdv/Downloads/plainwasmtest/hello.js:679:12
    at getExceptionMessageCommon (/home/swdv/Downloads/plainwasmtest/hello.js:1018:7)
    at getExceptionMessage (/home/swdv/Downloads/plainwasmtest/hello.js:1033:14)
    at ___throw_exception_with_stack_trace (/home/swdv/Downloads/plainwasmtest/hello.js:1038:19)
    at hello.wasm.__cxa_rethrow_primary_exception (wasm://wasm/hello.wasm-00c67b12:wasm-function[1749]:0x2c938)
    at hello.wasm.std::rethrow_exception(std::exception_ptr) (wasm://wasm/hello.wasm-00c67b12:wasm-function[70]:0x3270)
    at hello.wasm.__original_main (wasm://wasm/hello.wasm-00c67b12:wasm-function[12]:0x17c0)
    at hello.wasm.main (wasm://wasm/hello.wasm-00c67b12:wasm-function[63]:0x318f)
    at /home/swdv/Downloads/plainwasmtest/hello.js:679:12

• Also try with -DTWO_VIRTUAL for extra weird effects:

$ em++ -g -fwasm-exceptions main.cpp -o hello.js -DTWO_VIRTUAL

$ node hello.js

__cxa_current_exception_type: 4MyEx
typeid: 4MyEx
what: ERROR
rethrow_exception __cxa_current_exception_type: 4MyEx
rethrow_exception typeid: St13runtime_error
rethrow_exception what: ERRO
Aborted(native code called abort())
wasm://wasm/hello.wasm-00c67dd6:1


RuntimeError: unreachable
    at hello.wasm.__trap (wasm://wasm/hello.wasm-00c67dd6:wasm-function[2756]:0x402a1)
    at ___trap (/home/swdv/Downloads/plainwasmtest/hello.js:4074:54)
    at abort (/home/swdv/Downloads/plainwasmtest/hello.js:661:5)
    at __abort_js (/home/swdv/Downloads/plainwasmtest/hello.js:1043:7)
    at hello.wasm.abort (wasm://wasm/hello.wasm-00c67dd6:wasm-function[76]:0x3412)
    at hello.wasm.emscripten_builtin_free (wasm://wasm/hello.wasm-00c67dd6:wasm-function[127]:0x7f23)
    at hello.wasm.operator delete(void*) (wasm://wasm/hello.wasm-00c67dd6:wasm-function[1657]:0x2ace3)
    at hello.wasm.std::__2::__libcpp_refstring::~__libcpp_refstring() (wasm://wasm/hello.wasm-00c67dd6:wasm-function[1837]:0x2e286)
    at hello.wasm.std::runtime_error::~runtime_error() (wasm://wasm/hello.wasm-00c67dd6:wasm-function[1843]:0x2e2ef)
    at hello.wasm.MyEx::~MyEx() (wasm://wasm/hello.wasm-00c67dd6:wasm-function[15]:0x1b84)

Note that it says rethrow_exception typeid: St13runtime_error, which makes no sense.

• And here's what happens with -fsanitize=address:

Output

$ em++ -g main.cpp -fwasm-exceptions -o hello.js -DTWO_VIRTUAL -fsanitize=address

$ node hello.js

__cxa_current_exception_type: 4MyEx
typeid: 4MyEx
what: ERROR
warning: Invalid UTF-8 leading byte 0x0000008c encountered when deserializing a UTF-8 string in wasm memory to a JS string!
rethrow_exception __cxa_current_exception_type: 4MyEx
rethrow_exception typeid: St13runtime_error
rethrow_exception what: =================================================================
==42==ERROR: AddressSanitizer: heap-use-after-free on address 0x13c00b8c at pc 0x00007fd8 bp 0x12961040 sp 0x1296104c
READ of size 1 at 0x13c00b8c thread T0
    #0 0x00007fd8 in strlen+0x7fd8 (/home/swdv/Downloads/plainwasmtest/hello.js+0x7fd8)

0x13c00b8c is located 12 bytes inside of 18-byte region [0x13c00b80,0x13c00b92)
freed by thread T0 here:
    #0 0x0004c115 in free+0x4c115 (/home/swdv/Downloads/plainwasmtest/hello.js+0x4c115)
    #1 0x0003a590 in operator delete(void*)+0x3a590 (/home/swdv/Downloads/plainwasmtest/hello.js+0x3a590)
    #2 0x0003de5e in std::__2::__libcpp_refstring::~__libcpp_refstring()+0x3de5e (/home/swdv/Downloads/plainwasmtest/hello.js+0x3de5e)
    #3 0x0003dec7 in std::runtime_error::~runtime_error()+0x3dec7 (/home/swdv/Downloads/plainwasmtest/hello.js+0x3dec7)
    #4 0x000036cb in MyEx::~MyEx()+0x36cb (/home/swdv/Downloads/plainwasmtest/hello.js+0x36cb)
    #5 0x0007b88e in __get_exception_message+0x7b88e (/home/swdv/Downloads/plainwasmtest/hello.js+0x7b88e)
    #6 0x80000387  (JavaScript+0x387)

previously allocated by thread T0 here:
    #0 0x0004c2e8 in malloc+0x4c2e8 (/home/swdv/Downloads/plainwasmtest/hello.js+0x4c2e8)
    #1 0x0003a552 in operator_new_impl(unsigned long)+0x3a552 (/home/swdv/Downloads/plainwasmtest/hello.js+0x3a552)
    #2 0x0003a528 in operator new(unsigned long)+0x3a528 (/home/swdv/Downloads/plainwasmtest/hello.js+0x3a528)
    #3 0x0003a6c3 in std::__2::__libcpp_refstring::__libcpp_refstring(char const*)+0x3a6c3 (/home/swdv/Downloads/plainwasmtest/hello.js+0x3a6c3)
    #4 0x0003a791 in std::runtime_error::runtime_error(std::__2::basic_string<char, std::__2::char_traits<char>, std::__2::allocator<char>> const&)+0x3a791 (/home/swdv/Downloads/plainwasmtest/hello.js+0x3a791)
    #5 0x000034f0 in MyEx::MyEx(std::__2::basic_string<char, std::__2::char_traits<char>, std::__2::allocator<char>>)+0x34f0 (/home/swdv/Downloads/plainwasmtest/hello.js+0x34f0)
    #6 0x00002198 in __original_main+0x2198 (/home/swdv/Downloads/plainwasmtest/hello.js+0x2198)

SUMMARY: AddressSanitizer: heap-use-after-free (/home/swdv/Downloads/plainwasmtest/hello.js+0x7fd4) in strlen+0x7fd4
Shadow bytes around the buggy address:
  0x13c00900: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x13c00980: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x13c00a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x13c00a80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x13c00b00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x13c00b80: fd[fd]fd fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x13c00c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x13c00c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x13c00d00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x13c00d80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x13c00e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==42==ABORTING
AddressSanitizer: nested bug in the same thread, aborting.
libc++abi: terminating
Aborted(native code called abort())
wasm://wasm/hello.wasm-014fc232:1


RuntimeError: unreachable
    at hello.wasm.__trap (wasm://wasm/hello.wasm-014fc232:wasm-function[2811]:0x6a51b)
    at ___trap (/home/swdv/Downloads/plainwasmtest/hello.js:4636:54)
    at abort (/home/swdv/Downloads/plainwasmtest/hello.js:886:5)
    at __abort_js (/home/swdv/Downloads/plainwasmtest/hello.js:4040:24)
    at hello.wasm.abort (wasm://wasm/hello.wasm-014fc232:wasm-function[121]:0x800f)
    at hello.wasm.abort_message (wasm://wasm/hello.wasm-014fc232:wasm-function[1978]:0x3c775)
    at hello.wasm.demangling_terminate_handler() (wasm://wasm/hello.wasm-014fc232:wasm-function[1979]:0x3c901)
    at hello.wasm.std::__terminate(void (*)()) (wasm://wasm/hello.wasm-014fc232:wasm-function[2000]:0x3cb64)
    at hello.wasm.std::terminate() (wasm://wasm/hello.wasm-014fc232:wasm-function[1998]:0x3cb27)
    at hello.wasm.__cxa_decrement_exception_refcount (wasm://wasm/hello.wasm-014fc232:wasm-function[1950]:0x3be9b)

I discovered this when a Boost exception triggered this bug via boost::throw_exception, which throws boost::wrapexcept (possibly adding line info), which first inherits from some Boost class with virtual methods and then from the exception class you put into it. Example: BOOST_THROW_EXCEPTION(std::logic_error("Some logic error"));.

(This also happens with -sMEMORY64, btw.)

Expected behavior

$ clang++ main.cpp -o hello
$ ./hello
__cxa_current_exception_type: 4MyEx
typeid: 4MyEx
what: ERROR
rethrow_exception __cxa_current_exception_type: 4MyEx
rethrow_exception typeid: 4MyEx
rethrow_exception what: ERROR

(Same with em++ -g main.cpp -fwasm-exceptions -o hello.js -sNO_ASSERTIONS, disabling EXCEPTION_STACK_TRACES.)

Version of emscripten/emsdk

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 4.0.3 (a9651ff57165f5710bb09a5fe52590fd6ddb72df)
clang version 21.0.0git (https:/github.com/llvm/llvm-project 6dc41a639334b913e762f65410fcd14a722b137f)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /home/swdv/emsdk/upstream/bin

[sbc100]

Just to confirm, this only happens with -fwasm-exceptions, not with -fexceptions?

[stevenwdv]

@sbc100 I couldn't get it to compile with -fexceptions, I got undefined symbol: __cxa_current_exception_type.
Any idea how to solve this?

I thought -mexception-handling might help but then clang crashes:

Clang crash

em++ -g -fexceptions main.cpp -o hello.js -mexception-handling -v
 "/home/swdv/emsdk/upstream/bin/clang++" -target wasm32-unknown-emscripten -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-cxx-exceptions -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --sysroot=/home/swdv/emsdk/upstream/emscripten/cache/sysroot -DEMSCRIPTEN -Xclang -iwithsysroot/include/fakesdl -Xclang -iwithsysroot/include/compat -g3 -fexceptions -mexception-handling -v -c main.cpp -o /tmp/emscripten_temp_53rae0zj/main_0.o
clang version 21.0.0git (https:/github.com/llvm/llvm-project 6dc41a639334b913e762f65410fcd14a722b137f)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /home/swdv/emsdk/upstream/bin
 (in-process)
 "/home/swdv/emsdk/upstream/bin/clang-21" -cc1 -triple wasm32-unknown-emscripten -emit-obj -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name main.cpp -mrelocation-model static -mframe-pointer=none -ffp-contract=on -fno-rounding-math -mconstructor-aliases -target-cpu generic -target-feature +exception-handling -fvisibility=hidden -debug-info-kind=constructor -dwarf-version=4 -debugger-tuning=gdb -fdebug-compilation-dir=/home/swdv/Downloads/plainwasmtest -v -fcoverage-compilation-dir=/home/swdv/Downloads/plainwasmtest -resource-dir /home/swdv/emsdk/upstream/lib/clang/21 -D EMSCRIPTEN -isysroot /home/swdv/emsdk/upstream/emscripten/cache/sysroot -internal-isystem /home/swdv/emsdk/upstream/emscripten/cache/sysroot/include/wasm32-emscripten/c++/v1 -internal-isystem /home/swdv/emsdk/upstream/emscripten/cache/sysroot/include/c++/v1 -internal-isystem /home/swdv/emsdk/upstream/lib/clang/21/include -internal-isystem /home/swdv/emsdk/upstream/emscripten/cache/sysroot/include/wasm32-emscripten -internal-isystem /home/swdv/emsdk/upstream/emscripten/cache/sysroot/include -fdeprecated-macro -ferror-limit 19 -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fcxx-exceptions -fexceptions -fcolor-diagnostics -iwithsysroot/include/fakesdl -iwithsysroot/include/compat -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-cxx-exceptions -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr -o /tmp/emscripten_temp_53rae0zj/main_0.o -x c++ main.cpp
clang -cc1 version 21.0.0git based upon LLVM 21.0.0git default target x86_64-unknown-linux-gnu
ignoring nonexistent directory "/home/swdv/emsdk/upstream/emscripten/cache/sysroot/include/wasm32-emscripten/c++/v1"
ignoring nonexistent directory "/home/swdv/emsdk/upstream/emscripten/cache/sysroot/include/wasm32-emscripten"
#include "..." search starts here:
#include <...> search starts here:
 /home/swdv/emsdk/upstream/emscripten/cache/sysroot/include/fakesdl
 /home/swdv/emsdk/upstream/emscripten/cache/sysroot/include/compat
 /home/swdv/emsdk/upstream/emscripten/cache/sysroot/include/c++/v1
 /home/swdv/emsdk/upstream/lib/clang/21/include
 /home/swdv/emsdk/upstream/emscripten/cache/sysroot/include
End of search list.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.	Program arguments: /home/swdv/emsdk/upstream/bin/clang++ -target wasm32-unknown-emscripten -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-cxx-exceptions -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --sysroot=/home/swdv/emsdk/upstream/emscripten/cache/sysroot -DEMSCRIPTEN -Xclang -iwithsysroot/include/fakesdl -Xclang -iwithsysroot/include/compat -g3 -fexceptions -mexception-handling -v -c main.cpp -o /tmp/emscripten_temp_53rae0zj/main_0.o
1.	<eof> parser at end of file
2.	Code generation
3.	Running pass 'Function Pass Manager' on module 'main.cpp'.
4.	Running pass 'WebAssembly Instruction Selection' on function '@__original_main'
 #0 0x000060501636f478 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/swdv/emsdk/upstream/bin/clang+++0x2f8c478)
 #1 0x000060501636c7de llvm::sys::RunSignalHandlers() (/home/swdv/emsdk/upstream/bin/clang+++0x2f897de)
 #2 0x000060501636e6cf llvm::sys::CleanupOnSignal(unsigned long) (/home/swdv/emsdk/upstream/bin/clang+++0x2f8b6cf)
 #3 0x00006050162cf8a9 CrashRecoverySignalHandler(int) (.llvm.9277339120677677918) CrashRecoveryContext.cpp:0:0
 #4 0x00007dfe0e842520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #5 0x000060501773382e llvm::SelectionDAGBuilder::visitCatchRet(llvm::CatchReturnInst const&) (/home/swdv/emsdk/upstream/bin/clang+++0x435082e)
 #6 0x000060501772d555 llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) (/home/swdv/emsdk/upstream/bin/clang+++0x434a555)
 #7 0x00006050177ebb55 llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator_w_bits<llvm::ilist_detail::node_options<llvm::Instruction, false, false, void, true, llvm::BasicBlock>, false, true>, llvm::ilist_iterator_w_bits<llvm::ilist_detail::node_options<llvm::Instruction, false, false, void, true, llvm::BasicBlock>, false, true>, bool&) (/home/swdv/emsdk/upstream/bin/clang+++0x4408b55)
 #8 0x00006050177eb730 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/home/swdv/emsdk/upstream/bin/clang+++0x4408730)
 #9 0x00006050177e7f32 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/home/swdv/emsdk/upstream/bin/clang+++0x4404f32)
#10 0x00006050177e58d4 llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/home/swdv/emsdk/upstream/bin/clang+++0x44028d4)
#11 0x00006050158733ec llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/home/swdv/emsdk/upstream/bin/clang+++0x24903ec)
#12 0x0000605015df0f0e llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/swdv/emsdk/upstream/bin/clang+++0x2a0df0e)
#13 0x0000605015dfa553 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/swdv/emsdk/upstream/bin/clang+++0x2a17553)
#14 0x0000605015df1e92 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/swdv/emsdk/upstream/bin/clang+++0x2a0ee92)
#15 0x0000605016c47994 clang::emitBackendOutput(clang::CompilerInstance&, clang::CodeGenOptions&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem>, std::__2::unique_ptr<llvm::raw_pwrite_stream, std::__2::default_delete<llvm::raw_pwrite_stream>>, clang::BackendConsumer*) (/home/swdv/emsdk/upstream/bin/clang+++0x3864994)
#16 0x0000605016c61042 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/home/swdv/emsdk/upstream/bin/clang+++0x387e042)
#17 0x00006050182e8a39 clang::ParseAST(clang::Sema&, bool, bool) (/home/swdv/emsdk/upstream/bin/clang+++0x4f05a39)
#18 0x00006050171b583d clang::FrontendAction::Execute() (/home/swdv/emsdk/upstream/bin/clang+++0x3dd283d)
#19 0x00006050170c68b0 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/home/swdv/emsdk/upstream/bin/clang+++0x3ce38b0)
#20 0x00006050172bb497 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/home/swdv/emsdk/upstream/bin/clang+++0x3ed8497)
#21 0x0000605014fc8f23 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/home/swdv/emsdk/upstream/bin/clang+++0x1be5f23)
#22 0x0000605014fc5423 ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&) driver.cpp:0:0
#23 0x0000605016f10109 void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<std::__2::optional<llvm::StringRef>>, std::__2::basic_string<char, std::__2::char_traits<char>, std::__2::allocator<char>>*, bool*) const::$_0>(long) Job.cpp:0:0
#24 0x00006050162cf628 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/home/swdv/emsdk/upstream/bin/clang+++0x2eec628)
#25 0x0000605016f0fa64 clang::driver::CC1Command::Execute(llvm::ArrayRef<std::__2::optional<llvm::StringRef>>, std::__2::basic_string<char, std::__2::char_traits<char>, std::__2::allocator<char>>*, bool*) const (/home/swdv/emsdk/upstream/bin/clang+++0x3b2ca64)
#26 0x0000605016ec98f8 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (/home/swdv/emsdk/upstream/bin/clang+++0x3ae68f8)
#27 0x0000605016eebadc clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::__2::pair<int, clang::driver::Command const*>>&) (/home/swdv/emsdk/upstream/bin/clang+++0x3b08adc)
#28 0x0000605014fc439c clang_main(int, char**, llvm::ToolContext const&) (/home/swdv/emsdk/upstream/bin/clang+++0x1be139c)
#29 0x0000605014fd487a main (/home/swdv/emsdk/upstream/bin/clang+++0x1bf187a)
#30 0x00007dfe0e829d90 __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#31 0x00007dfe0e829e40 call_init ./csu/../csu/libc-start.c:128:20
#32 0x00007dfe0e829e40 __libc_start_main ./csu/../csu/libc-start.c:379:5
#33 0x0000605014f2f9aa _start (/home/swdv/emsdk/upstream/bin/clang+++0x1b4c9aa)
clang++: error: clang frontend command failed with exit code 139 (use -v to see invocation)
clang version 21.0.0git (https:/github.com/llvm/llvm-project 6dc41a639334b913e762f65410fcd14a722b137f)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /home/swdv/emsdk/upstream/bin
clang++: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang++: note: diagnostic msg: /tmp/main-48a851.cpp
clang++: note: diagnostic msg: /tmp/main-48a851.sh
clang++: note: diagnostic msg: 

********************
em++: error: '/home/swdv/emsdk/upstream/bin/clang++ -target wasm32-unknown-emscripten -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-cxx-exceptions -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --sysroot=/home/swdv/emsdk/upstream/emscripten/cache/sysroot -DEMSCRIPTEN -Xclang -iwithsysroot/include/fakesdl -Xclang -iwithsysroot/include/compat -g3 -fexceptions -mexception-handling -v -c main.cpp -o /tmp/emscripten_temp_53rae0zj/main_0.o' failed (returned 1)

Idk, maybe that option does something unrelated?

[sbc100]

-fexceptions currently enables the old emscripten-style exceptions handling. -mexception-handling related to the new wasm exception handling proposal (you should never need to pass that yourself I think).

Regarding the missing __cxa_current_exception_type it does indeed look like we don't define for the emscripten-style exceptions, but nobody has reported that as an issue up until now. Would you mind opening a new issue for that? Does your repro case depend on being able to call that function?

[stevenwdv]

@sbc100 Oh wait I forgot I called that function myself 😅, I'll open a new issue though (#23734). No the repro shouldn't depend on that, I'll test without.

[stevenwdv]

@sbc100 No, apparently this issue does not occur with -fexceptions.