Rene Engelhard
2023-11-01 19:50:01 UTC
Hi,
since LibreOffice 7.6 (which added some more tests which were manual
before to the automatic set) the testtools' bridge test fails:
https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=armhf&ver=4%3A7.6.2-5&stamp=1698791231&raw=0
only on armhf. armel and arm64 just work.
it says
[build CHK] test
S=/<<PKGBUILDDIR>> && I=$S/instdir &&
W=$S/workdir && mkdir -p $W/Module/check/ && touch
$W/Module/check/test
S=/<<PKGBUILDDIR>> && I=$S/instdir &&
W=$S/workdir &&
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/progr
am:$I/program" $I/program/uno.bin -s
com.sun.star.test.bridge.BridgeTest --
com.sun.star.test.bridge.CppTestObject -env:LO_BUILD_LIB_DIR=file://$W/Link
Target/Library -env:URE_MORE_SERVICES=file://$W/Rdb/uno_services.rdb
-env:URE_MORE_TYPES=file://$W/UnoApiTarget/bridgetest.rdb &&
LD_LIBRARY_PATH=${L
D_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program"
$I/program/uno.bin -s com.sun.star.test.bridge.BridgeTest --
com.sun.star.test.bridge.Ja
vaTestObject noCurrentContext
-env:LO_BUILD_LIB_DIR=file://$W/LinkTarget/Library
-env:URE_MORE_SERVICES=file://$W/Rdb/uno_services.rdb
-env:URE_MORE_TYPES=fil
e://$W/UnoApiTarget/bridgetest.rdb
two floats struct test failed
*** stack smashing detected ***: terminated
Aborted (core dumped)
make[3]: ***
[/<<PKGBUILDDIR>>/testtools/CustomTarget_uno_test.mk:32:
/<<PKGBUILDDIR>>/workdir/CustomTarget/testtools/uno_test.done] E
rror 134
(Even though one probably shouldn't do it I did try to build it
- without -fstack-protector-strong -> with just -fstack-protector: fails
the same way
- without -fstack-protector:
Fails in a different way:
touch /data/ssd/rene/libreoffice-7.6.2/workdir/Executable/uno.run
S=/data/ssd/rene/libreoffice-7.6.2 && I=$S/instdir && W=$S/workdir &&
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program"
$I/program/uno.bin -s com.sun.star.test.bridge.BridgeTest --
com.sun.star.test.bridge.CppTestObject
-env:LO_BUILD_LIB_DIR=file://$W/LinkTarget/Library
-env:URE_MORE_SERVICES=file://$W/Rdb/uno_services.rdb
-env:URE_MORE_TYPES=file://$W/UnoApiTarget/bridgetest.rdb &&
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program"
$I/program/uno.bin -s com.sun.star.test.bridge.BridgeTest --
com.sun.star.test.bridge.JavaTestObject noCurrentContext
-env:LO_BUILD_LIB_DIR=file://$W/LinkTarget/Library
-env:URE_MORE_SERVICES=file://$W/Rdb/uno_services.rdb
-env:URE_MORE_TYPES=file://$W/UnoApiTarget/bridgetest.rdb
two floats struct test failed
four floats struct test failed
### float does not match! failed
### double does not match! failed
struct comparison test failed
armhf doubles test failed
### float does not match! failed
### double does not match! failed
recursive test results failed
remote multi failed: 0 != 6.38084e-314
standard test failed
exception occurred: error: test failed! at
./testtools/source/bridgetest/bridgetest.cxx:1275
/data/ssd/rene/libreoffice-7.6.2/workdir/CustomTarget/testtools/uno_test.done]
Error 1
So might it be the same failure mode as ppc64/s390x?
See the discussion upstream in
https://lists.freedesktop.org/archives/libreoffice/2023-September/thread.html:
"new bridgetest failures in 7.6 on ppc64le "
(while mentioning ppc64el initially s390x is affected, too)
and continued in October
https://lists.freedesktop.org/archives/libreoffice/2023-October/thread.html
especially
https://lists.freedesktop.org/archives/libreoffice/2023-October/091058.html
and
https://lists.freedesktop.org/archives/libreoffice/2023-October/091059.html
after which unfortunately noting important happened. (And I don't see a
patch either at Fedora git nor submitted upstream to fix this.)
This is probably architecture-specific since the other architectures
*do* work (except ppc64el and s390x).
Can you have a look at it?
(The workaround would be --without-java which I verified to work on my
rpi4, but this opens a can of worms. Not only disabling some (built-in)
features like the Report Builder but especially since there is
Java-based extensions (_all!) which then get into trouble
dependency-wise/LO will be blocked from migrating to testing maybe...)
Regards,
Rene
since LibreOffice 7.6 (which added some more tests which were manual
before to the automatic set) the testtools' bridge test fails:
https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=armhf&ver=4%3A7.6.2-5&stamp=1698791231&raw=0
only on armhf. armel and arm64 just work.
it says
[build CHK] test
S=/<<PKGBUILDDIR>> && I=$S/instdir &&
W=$S/workdir && mkdir -p $W/Module/check/ && touch
$W/Module/check/test
S=/<<PKGBUILDDIR>> && I=$S/instdir &&
W=$S/workdir &&
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/progr
am:$I/program" $I/program/uno.bin -s
com.sun.star.test.bridge.BridgeTest --
com.sun.star.test.bridge.CppTestObject -env:LO_BUILD_LIB_DIR=file://$W/Link
Target/Library -env:URE_MORE_SERVICES=file://$W/Rdb/uno_services.rdb
-env:URE_MORE_TYPES=file://$W/UnoApiTarget/bridgetest.rdb &&
LD_LIBRARY_PATH=${L
D_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program"
$I/program/uno.bin -s com.sun.star.test.bridge.BridgeTest --
com.sun.star.test.bridge.Ja
vaTestObject noCurrentContext
-env:LO_BUILD_LIB_DIR=file://$W/LinkTarget/Library
-env:URE_MORE_SERVICES=file://$W/Rdb/uno_services.rdb
-env:URE_MORE_TYPES=fil
e://$W/UnoApiTarget/bridgetest.rdb
two floats struct test failed
*** stack smashing detected ***: terminated
Aborted (core dumped)
make[3]: ***
[/<<PKGBUILDDIR>>/testtools/CustomTarget_uno_test.mk:32:
/<<PKGBUILDDIR>>/workdir/CustomTarget/testtools/uno_test.done] E
rror 134
(Even though one probably shouldn't do it I did try to build it
- without -fstack-protector-strong -> with just -fstack-protector: fails
the same way
- without -fstack-protector:
Fails in a different way:
touch /data/ssd/rene/libreoffice-7.6.2/workdir/Executable/uno.run
S=/data/ssd/rene/libreoffice-7.6.2 && I=$S/instdir && W=$S/workdir &&
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program"
$I/program/uno.bin -s com.sun.star.test.bridge.BridgeTest --
com.sun.star.test.bridge.CppTestObject
-env:LO_BUILD_LIB_DIR=file://$W/LinkTarget/Library
-env:URE_MORE_SERVICES=file://$W/Rdb/uno_services.rdb
-env:URE_MORE_TYPES=file://$W/UnoApiTarget/bridgetest.rdb &&
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program"
$I/program/uno.bin -s com.sun.star.test.bridge.BridgeTest --
com.sun.star.test.bridge.JavaTestObject noCurrentContext
-env:LO_BUILD_LIB_DIR=file://$W/LinkTarget/Library
-env:URE_MORE_SERVICES=file://$W/Rdb/uno_services.rdb
-env:URE_MORE_TYPES=file://$W/UnoApiTarget/bridgetest.rdb
two floats struct test failed
four floats struct test failed
### float does not match! failed
### double does not match! failed
struct comparison test failed
armhf doubles test failed
### float does not match! failed
### double does not match! failed
recursive test results failed
remote multi failed: 0 != 6.38084e-314
standard test failed
exception occurred: error: test failed! at
./testtools/source/bridgetest/bridgetest.cxx:1275
error: error: test failed! at
./testtools/source/bridgetest/bridgetest.cxx:1275dying...make: ***
[/data/ssd/rene/libreoffice-7.6.2/testtools/CustomTarget_uno_test.mk:32:/data/ssd/rene/libreoffice-7.6.2/workdir/CustomTarget/testtools/uno_test.done]
Error 1
So might it be the same failure mode as ppc64/s390x?
See the discussion upstream in
https://lists.freedesktop.org/archives/libreoffice/2023-September/thread.html:
"new bridgetest failures in 7.6 on ppc64le "
(while mentioning ppc64el initially s390x is affected, too)
and continued in October
https://lists.freedesktop.org/archives/libreoffice/2023-October/thread.html
especially
https://lists.freedesktop.org/archives/libreoffice/2023-October/091058.html
and
https://lists.freedesktop.org/archives/libreoffice/2023-October/091059.html
after which unfortunately noting important happened. (And I don't see a
patch either at Fedora git nor submitted upstream to fix this.)
This is probably architecture-specific since the other architectures
*do* work (except ppc64el and s390x).
Can you have a look at it?
(The workaround would be --without-java which I verified to work on my
rpi4, but this opens a can of worms. Not only disabling some (built-in)
features like the Report Builder but especially since there is
Java-based extensions (_all!) which then get into trouble
dependency-wise/LO will be blocked from migrating to testing maybe...)
Regards,
Rene