On 18.02.2018 16:44, jan iversen wrote:
frame.cxx, 1270, implts_sendFrameActionEvent(
css::frame::FrameAction_FRAME_ACTIVATED );
cpp2uno.cxx, 204 (Mac version) CPPU_CURRENT_NAMESPACE::raiseException(
&aUnoExc, pThis->getBridge()->getUno2Cpp() ); // has to destruct the any
except.cxx, 290 (Mac version) void raiseException( uno_Any * pUnoExc,
uno_Mapping * pUno2Cpp )
line 341 in raisException: __cxxabiv1::__cxa_throw( pCppExc, rtti,
deleteException );
calls:
exc_thrower.cxx, 205, Any SAL_CALL getCaughtException()
and then
uno2cpp.cxx, 305, unoInterfaceProxyDispatch()
as expected.
Doing the same on the device, everything is identical until
line 341 in raisException: __cxxabiv1::__cxa_throw( pCppExc, rtti,
deleteException );
which throws an exception that ends up in LoadEnv::~LoadEnv().
So in the first case the (synthetically) thrown exception is apparently
caught by some exception handler for some type T, while in the second
case that fails for whatever reason, and exception handling proceeds
past that dismissed handler, and happens to call a LoadEnv dtor during
stack unwinding.
The most likely reason for that handler for type T to be dismissed is
that, while the (synthetically) thrown exception is nominally of type T
or some type derived from it, the type info does not match. (The
libc++abi used on macOS and iOS uses the strict Itanium ABI rule of
address equivalence for RTTI equivalence.)
Does the dlsym call
rtti = static_cast<std::type_info *>(dlsym( m_hApp, symName.getStr() ));
in RTTI::getRTTI in bridges/source/cpp_uno/gcc3_ios/except.cxx fail when
it shouldn't (because the relevant RTTI is already emitted in the LO code)?
_______________________________________________
LibreOffice mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
