`std::current_exception` is NULL in termination handler

[stevenwdv]

std::current_exception is nullptr when called from a termination handler.

Steps to reproduce

• Create main.cpp with the following contents:

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

static void printCurrentException() {
	auto exPtr = std::current_exception();
	std::cerr << "exception_ptr = ";
	if (exPtr)
		try {
			std::rethrow_exception(std::move(exPtr));
		} catch (const std::runtime_error &ex) {
			std::cerr << "runtime_error: " << ex.what() << '\n';
		} catch (...) {
			std::cerr << "non-runtime_error\n";
		}
	else std::cerr << "NULL\n";
}

void noThrow() noexcept {
	try {
		throw std::runtime_error("error1");
	} catch (...) {
		printCurrentException();
	}
	std::set_terminate([] {
		printCurrentException();
		std::abort();
	});
	throw std::runtime_error("error2");
}

int main() {
	noThrow();
}

• Now compile with exceptions (optionally with debug symbols):

em++ -fexceptions 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

exception_ptr = runtime_error: error1
exception_ptr = NULL
Aborted(native code called abort())

• Note that std::current_exception() was properly set in the catch block, but the termination handler got a nullptr, while it should've been a pointer wrapping std::runtime_error("error2").

The same happens with -fwasm-exceptions and -fwasm-exceptions -sNO_WASM_LEGACY_EXCEPTIONS (run with --experimental-wasm-exnref as first parameter to node).

Details

The standard says the following

constexpr exception_ptr current_exception() noexcept;

9. Returns: An exception_ptr object that refers to the currently handled exception or a copy of the currently handled exception, or a null exception_ptr object if no exception is being handled.
   [...]

and:

8. If no matching handler is found, the function std​::​terminate is invoked; whether or not the stack is unwound before this invocation of std​::​terminate is implementation-defined ([except.terminate]).
9. A handler is considered active when initialization is complete for the parameter (if any) of the catch clause.
   [Note 4: The stack will have been unwound at that point.
   — end note]
   Also, an implicit handler is considered active when the function std​::​terminate is entered due to a throw.
   A handler is no longer considered active when the catch clause exits.
10. The exception with the most recently activated handler that is still active is called the currently handled exception.

So, as I understand it, the "implicit handler" should be active at this point. Besides, it works fine when compiled for x86 using Clang or GCC.

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

[aheejin]

This does not work because we don't have the two-phase exception handling.

---

Wasm EH

When an exception is thrown and there is no handler to catch it, the terminate handler is run here in failed_throw

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

Line 152 in de54d21

std::__terminate(exception_header->terminateHandler);

And this failed_throw is called here in __cxa_throw, after _UnwindRaiseException:

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

Lines 299 to 310 in de54d21

	#ifdef __USING_SJLJ_EXCEPTIONS__
	_Unwind_SjLj_RaiseException(&exception_header->unwindHeader);
	#elif defined(__EMSCRIPTEN__) && defined(__WASM_EXCEPTIONS__) && !defined(NDEBUG)
	// 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);
	#else
	_Unwind_RaiseException(&exception_header->unwindHeader);
	#endif
	// This only happens when there is no handler, or some unexpected unwinding
	// error happens.
	failed_throw(exception_header);

So this is called only when _Unwind_RaiseException returns.

This is how this goes In case of x86 Itanium EH:
_UnwindRaiseException first scans the stack to search for a handler (phase 1), and if one is found, goes to the phase 2. If no handler is found, it just returns without going to the phase 2.

emscripten/system/lib/libunwind/src/UnwindLevel1.c

Lines 458 to 464 in de54d21

	// phase 1: the search phase
	_Unwind_Reason_Code phase1 = unwind_phase1(&uc, &cursor, exception_object);
	if (phase1 != _URC_NO_REASON)
	return phase1;
	// phase 2: the clean up phase
	return unwind_phase2(&uc, &cursor, exception_object);

Even if it looks like it also returns after phase 2, once it goes to the phase 2, this function does not return to __cxa_throw, because unwind_phase2 will change the SP. So in the two-phase EH, failed_throw will only be called when there is no handler found and only the phase 1 has run.

The two-phase EH's advantage is that in case no handler is found, we don't need to unwind the whole stack and the stack can be preserved for inspection when the program crashes.

Wasm does not support two phase EH because the stack examination and unwinding is done not by libunwind like in the case of x86 but the VM itself, and the EH proposal currently does not provide the functionality of "stack examination without unwinding". (This has been discussed but this is not trivial, because the unwinder has to stop at each stack frame and needs to call the personality function, which is a userspace function in libc++abi. But making the spec so that the VM can call a specific userspace function is complicated. So it was decided that the scope of the current EH proposal did not include two-phase EH, which does not necessarily preclude the possibility of such proposal in future, but no related work is currently planned or underway.)

So when searching for a handler, Wasm EH just unwinds stack frames one by one, and if no handler is found, there's no stack frame anymore and it just crashes. So we cannot return to __cxa_throw to run failed_throw. Was's _Unwind_RaiseException just runs Wasm's throw instruction and the rest is done by the VM:

emscripten/system/lib/libunwind/src/Unwind-wasm.c

Lines 63 to 70 in de54d21

	/// Called by __cxa_throw.
	_LIBUNWIND_EXPORT _Unwind_Reason_Code
	_Unwind_RaiseException(_Unwind_Exception *exception_object) {
	_LIBUNWIND_TRACE_API("_Unwind_RaiseException(exception_object=%p)",
	(void *)exception_object);
	// Use Wasm EH's 'throw' instruction.
	__builtin_wasm_throw(0, exception_object);
	}

---

Emscripten EH

The problem is similar in Emscripten EH. Emscripten EH (-fexceptions) uses JS exceptions to simulate exception throwing, and JS does not have the two-phase EH. Emscripten EH does not use __cxa_throw in libc++abi but uses a JS function here:

emscripten/src/lib/libexceptions.js

Lines 89 to 99 in de54d21

	__cxa_throw: (ptr, type, destructor) => {
	#if EXCEPTION_DEBUG
	dbg('__cxa_throw: ' + [ptrToString(ptr), type, ptrToString(destructor)]);
	#endif
	var info = new ExceptionInfo(ptr);
	// Initialize ExceptionInfo content after it was allocated in __cxa_allocate_exception.
	info.init(type, destructor);
	{{{ storeException('exceptionLast', 'ptr') }}}
	uncaughtExceptionCount++;
	{{{ makeThrow('exceptionLast') }}}
	},

This, of course, does not have a way to call the terminate handler.

---

While I can't think of any good way to support std::set_terminate with the current EH schemes, maybe we should document this in the EH related docs.

[stevenwdv]

@aheejin Thanks so much for the details!

You seem to suggest that set_terminate doesn't work at all, but it does (see example above). The problem I mentioned is that current_exception is NULL.
Note that my example explicitly has a noexcept function, maybe you're talking about when an exception escapes main instead?

[aheejin]

@stevenwdv Ah you're right. What I described in #23720 (comment) was only half the reason and applies to the case when there is no noexcept. I was testing with my own smaller test case which didn't have the noexcept so I was confused.

So the case of noexcept here can be generalized as when an exception thrown ends up calling std::terminate. This can happen with noexcept but also when a library function (such as __cxa_end_catch) throws in the process of handling the previous exception.

Anyway in case of this noexcept case, when the second exception is thrown and the function cannot throw, std::terminate is called. According to the libc++abi spec, __cxa_begin_catch should be called before std::terminate: https://libcxxabi.llvm.org/spec.html

When the personality routine encounters a termination condition, it will call __cxa_begin_catch() to mark the exception as handled and then call terminate(), which shall not return to its caller.

In case of x86 Itanium, a call to __clang_call_terminate is generated, which calls __cxa_begin_catch and then std::terminate: (the below is the bitcode ll file)

define dso_local void @_Z7noThrowv() personality ptr @__gxx_personality_v0 {
...

terminate.lpad:                                   ; preds = %invoke.cont6, %try.cont, %invoke.cont2, %catch
  %7 = landingpad { ptr, i32 }
          catch ptr null
  %8 = extractvalue { ptr, i32 } %7, 0
  call void @__clang_call_terminate(ptr %8)
  unreachable
}
...

define linkonce_odr hidden void @__clang_call_terminate(ptr noundef %0) #4 comdat {
  %2 = call ptr @__cxa_begin_catch(ptr %0)
  call void @_ZSt9terminatev()
  unreachable
}
...

We used to do this but after llvm/llvm-project@561abd8 we replaced __clang_call_terminate with std::terminate, removing __cxa_begin_catch call. The main reason was mostly it was a lot more convenient that way and we needed more engineering effort supporting the precise spec.

The reason std::current_exception didn't work was, it calls __cxa_current_primary_exception, which accesses global->caughtException:

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

Line 731 in 1cebdf5

__cxa_exception* exception_header = globals->caughtExceptions;

And this was supposed to set in __cxa_begin_catch:

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

Line 492 in 1cebdf5

globals->caughtExceptions = exception_header;

So yeah in this case set_terminate works, because we call std::terminate, but the current exception pointer is NULL.

---

So to summarize,

1. In case an exception unwinds all stack and crashes (std::current_exception is NULL in termination handler #23720 (comment)): Because we don't have two-phase EH, we don't get to call std::terminate at all and std::set_terminate does not work. This is unfixable with the current Wasm EH proposal and also in the Emscripten EH.

2. In case of an exception causes std::terminate to be called (either because of noexcept or another exception is thrown during handling the first exception) (this comment): We call std::terminate but we don't call __cxa_begin_catch before it as we are supposed to. So we don't end up setting the current exception pointer, which causes std::current_exception to fail. This is fixable but requires more implementation which I'm not very sure is worth it.

Unless there is a very compelling use case that the 2 scenario definitely has to work, I'd like to document the limitation as I did for the case 1. What do you think?

[stevenwdv]

@aheejin Right, thanks! I thought it probably had something to do with __cxa_begin_catch not being called.

2. Unless there is a very compelling use case that the 2 scenario definitely has to work, I'd like to document the limitation as I did for the case 1. What do you think?

I don't really grasp what the difficulty was with __clang_call_terminate as I don't know anything about cleanup pads etc., so idk how hard it is to fix, and in any case it should be probably documented until it's fixed.
However, I do think it would be unfortunate if it would stay this way, because then in noexcept functions, such as (often) move operations and destructors, if an uncaught exception occurs there is no way to print that exception.

[aheejin]

I documented both limitations in #23728. The first one is basically not fixable currently and the second one may be fixed in the future, but I think both warrant documentation.

I also filed a separate issue #23779, which describes the second problem (#23720 (comment)), for the purpose of quicker reference (than this long-ish discussion). The first problem is unfixable so I don't think we need a separate issue for that.

How about closing this issue given that we have #23779?