On 8/31/23 13:51, Dan Horák wrote:
On Thu, 31 Aug 2023 10:21:05 +0200
Dan Horák <dan@xxxxxxxx> wrote:
Hello,
I am working with the Fedora LibreOffice team on keeping LO building on
ppc64le and s390x platforms and we found some new test failures during the
rebase to 7.6. This is the first of them.
...
[CXX] vcl/qa/cppunit/GraphicTest.cxx
[CXX] vcl/qa/cppunit/GraphicDescriptorTest.cxx
two floats struct test failed
four floats struct test failed
standard test failed
exception occurred: error: test failed! at /home/sharkcz/projects/libreoffice/testtools/source/bridgetest/bridgetest.cxx:1268
error: error: test failed! at /home/sharkcz/projects/libreoffice/testtools/source/bridgetest/bridgetest.cxx:1268
dying...make[1]: *** [/home/sharkcz/projects/libreoffice/testtools/CustomTarget_uno_test.mk:26: /home/sharkcz/projects/libreoffice/workdir/CustomTarget/testtools/uno_test.done] Error 1
make[1]: *** Waiting for unfinished jobs....
I have tracked it down to
https://git.libreoffice.org/core/+/32c845cb4389aba9430ce471b04f2891f5ff630d%5E%21/
So I guess it possibly uncovered a real issue somewhere else.
Seems the TwoFloat/FourFloat checks from
https://git.libreoffice.org/core/+/refs/heads/master/testtools/source/bridgetest/bridgetest.cxx#472
are called twice during "make unitcheck" and the second run returns
garbage in the second (and third/fourth?) member. Any pointers where to
look further or any help on resolving it would be appreciated.
and before the mentioned commit the check is run only once. Doesn't it
mean the Java bridge is broken for ppc64le, because it now runs the
Java test as well?
Smells a bit like it, though that would also be somewhat odd as that
bridge should mostly be platform-agnostic.
While the first test checks a roundtrip from C++
(testtools/source/bridgetest/bridgetest.cxx) to the binary UNO hub to
C++ (testtools/source/bridgetest/cppobj.cxx) and back, that second test
checks a roundtrip form C++ (testtools/source/bridgetest/bridgetest.cxx)
to the binary UNO hub to Java
(testtools/com/sun/star/comp/bridge/TestComponent.java) and back.
Maybe bridges/source/jni_uno/jni_data.cxx Bridge::map_to_uno/_java are
good first pointers where to look for corrupted values in-flight, and
then go from there...
