Exception state can be saved to incorrect thread in 1.88

[zhykzhykzhyk]

The manage_exception_state try to save and restore the exception state from/to the current thread that executing the fiber, but only one __cxa_get_globals() call is generated for the outer function after optimization, which would be incorrect if fiber resume on another thread.

context/include/boost/context/fiber_fcontext.hpp

Lines 88 to 98 in 6ff80e0

	class manage_exception_state {
	public:
	manage_exception_state() {
	exception_state_ = *__cxa_get_globals();
	}
	~manage_exception_state() {
	*__cxa_get_globals() = exception_state_;
	}
	private:
	__cxa_eh_globals exception_state_;
	};

Result from compiler explorer

// check disassembly of this function
void foo(boost::context::fiber&& f) { std::move(f).resume(); }

[vasily-sviridov]

Hi, @olk, @zhykzhykzhyk - checking if there's any update on this.

PR #324 was merged on Mar 10, but the fix doesn't seem to be present in develop anymore. The manager_exception_state class in fiber_fcontext.hpp is back to the original version without BOOST_NOINLINE / volatile.

We're hitting this in production with Boost version more that 1.87 - the compiler caches the __cxa_get_globals pointer across the context switch, so exception state ends up in the wrong thread after a fiber resumes elsewhere. Same symptoms as the original issue.

Was the PR intentionally reverted, or did it get lost in a branch shuffle? Just wondering if a fix is still on the roadmap, or if there's a recommended workaround in the meantime.

[vasily-sviridov]

I opened #331 to re-apply the fix from #324, which doesn't seem to be in develop anymore (not sure what happened, looks like it got caught in the revert after the build failures).

We're hitting this in production on Boost 1.87+ and confirmed that the BOOST_NOINLINE approach from da3fa4f fixes it for us. Also found the same root cause documented in userver-framework/userver#242 if more context is helpful.