new bridgetest failures in 7.6 on ppc64le

Stephan Bergmann sbergman at redhat.com
Thu Oct 5 15:11:55 UTC 2023


On 10/5/23 10:38, Dan Horák wrote:
> I would appreciate any tips and tricks how to attack this problem with
> gdb, because I wasn't successful in getting into the right place or
> process and relied mainly on the old school "printf" method :-)

The call

>             TwoFloats aOut = xLBT->echoTwoFloats(aIn);

at testtools/source/bridgetest/bridgetest.cxx:474 goes to a dynamically 
created stub, generated at runtime by codeSnippet in 
bridges/source/cpp_uno/gcc3_linux_powerpc64/cpp2uno.cxx, which calls 
privateSnippetExecutor, which calls cpp_mediate, which (in its case 
typelib_TypeClass_INTERFACE_METHOD case's default case) calls 
cpp2uno_call, which at

>     // invoke uno dispatch call
>     (*pThis->getUnoI()->pDispatcher)( pThis->getUnoI(), pMemberTypeDescr, pUnoReturn, pUnoArgs, &pUnoExc );

calls into the binary UNO to Java bridge.  So if you assume that things 
are fine between binary UNO and Java (which is a reasonable assumption, 
as that part should be mostly architecture-agnostic), I'd start to debug 
at the return of that pDispatcher call, and see how its return value 
(i.e., the return value from

>         public TwoFloats echoTwoFloats( TwoFloats i_Struct) throws com.sun.star.uno.RuntimeException {
>             return i_Struct;
>         }

in testtools/com/sun/star/comp/bridge/TestComponent.java) propagates 
back down to the original C++ call at 
testtools/source/bridgetest/bridgetest.cxx:474.



More information about the LibreOffice mailing list