Re: cpp2uno throw problems.

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)?