cpp2uno throw problems.
Stephan Bergmann
sbergman at redhat.com
Sun Feb 18 21:54:39 UTC 2018
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)?
More information about the LibreOffice
mailing list