Re: Arch-specific test failures
On Mon, 12 Feb 2024 09:49:31 + Caolán McNamara wrote: > On Fri, 2024-02-09 at 21:34 +, Gwyn Ciesla wrote: > > ppc64le > > CppunitTest_dbaccess_RowSetClones > > I think this one has been around for ages in the fedora build. But I > don't know if we even have a backtrace for that failure? > https://github.com/sharkcz/LibreOffice-core/commit/be0e8e6205734784c7957e1f3520ada878572d8a contains my notes about the issue. IIRC I was able to get a backtrace, but the Java inside makes it difficult to understand ... Dan
Re: Arch-specific test failures
On Mon, 12 Feb 2024 08:55:36 +0100 Miklos Vajna wrote: > Hi Gwyn, > > On Fri, Feb 09, 2024 at 09:34:07PM +, Gwyn Ciesla > wrote: > > s390x > > > > CppunitTest_dbaccess_RowSetClones: SwMacrosTest::testVba > > > > CustomTarget_uno_test: > > https://bugs.documentfoundation.org/show_bug.cgi?id=125978 > > > > CppunitTest_basic_macros: testTdf149402_vba > > > > CppunitTest_vcl_svm_test > > CppunitTest_sw_core_layout > > CppunitTest_desktop_lib: > > https://bugs.documentfoundation.org/show_bug.cgi?id=158722 > > CppunitTest_vcl_png_test: > > https://bugs.documentfoundation.org/show_bug.cgi?id=159184 > > CppunitTest_sd_png_export_tests: > > https://bugs.documentfoundation.org/show_bug.cgi?id=159211 > > > > Please let me know if you submit a patch to gerrit for any of these, and > > I'll help test. > > Is it correct to assume that most of these will be around big-endian and > not s390x specifically? I believe so, I have already looked at some of these and they were most likely big endian related. Dan
Re: Is it still possible to compile LibreOffice 24 for Linux 32-bit?
On Wed, 7 Feb 2024 12:51:06 -0600 Escuelas Linux wrote: > The release notes for the latest version of LibreOffice (24.2) state that > > > "The minimum requirements for building and running LibreOffice on Linux > have been raised from Red Hat Enterprise Linux 7/CentOS 7 to Red Hat > Enterprise Linux 8/CentOS 8 (or equivalent)". > > > Since Red Hat/CentOS 8 does not have a 32-bit edition, I wonder if my > problems compiling for 32-bit are due to a possible lack of support. > > I have been compiling LibreOffice for Linux 32-bit since the Foundation > stopped releasing 32-bit binaries. I have been able to solve problems, > sometimes on my own, sometimes with the generous help of people on this > very mailing list. > > But now I'm stuck. > > I am using Debian 12 Bookworm 32-bit as my OS base. I downloaded all the > dependencies asked for on the BuildingOnLinux Foundation wiki. > > Since trying to compile 24.2 with a simple 'make' treats all warnings as > errors, I tried using > > > make CFLAGS="-Wno-error" CXXFLAGS="-Wno-error" > > > But this approach only resulted in some non-compileable modules. > > I was finally able to compile most of them using > > > make -Wall -Wno-restrict > > > But it stops at one of the last stages with this message: > > > "/usr/bin/ld: Error: /tmp/ccDBatVc.ltrans0.ltrans.o(.data.rel.ro) is too > big (0x3ef58 bytes) > > /usr/bin/ld: Could not set dynamic section sizes: memory exhausted > > collect2: Error: ld returned 1 exit state > > make[1]: *** > [/home/linux/Downloads/libreoffice-24.2.0.3/Library_merged.mk:11: > /home/linux/Downloads/libreoffice-24.2.0.3/instdir/program/libmergedlo.so] > Error" > > > Since I have allocated 12 GB of RAM in the virtual machine, I don't know > why the memory is exhausted. because 32-bit system means max 4GB of address space for a process and ld runs as a single process you can try disabling or reducing the size of debuginfo to reduce the size of the *.o files if it's used, you can disable LTO and there are some options for ld to reduce its memory consumption a bit Dan
Re: new ScPDFExportTest::testTdf123870() won't compile
On Tue, 9 Jan 2024 08:48:13 +0100 Stephan Bergmann wrote: > On 1/9/24 08:45, Dan Horák wrote: > > seems that with > > https://cgit.freedesktop.org/libreoffice/core/commit/?id=b3c93b16d62e80955edc749af4b8ad10162c > > the new testTdf123870() won't compile > > > > ... > > /home/jenkins/workspace/libreoffice-upstream-bundled/label/mt-snow-02-brq/sc/qa/extras/scpdfexport.cxx: > > In member function ‘void ScPDFExportTest::testTdf123870()’: > > /home/jenkins/workspace/libreoffice-upstream-bundled/label/mt-snow-02-brq/sc/qa/extras/scpdfexport.cxx:399:5: > > error: ‘loadFromURL’ was not declared in this scope; did you mean > > ‘loadFromFile’? > >399 | loadFromURL(u"tdf123870.ods"); > >| ^~~ > >| loadFromFile > > ... > > see <https://gerrit.libreoffice.org/c/core/+/161812> "Fix build" thanks, I have checked current git, but not gerrit :-) Dan
new ScPDFExportTest::testTdf123870() won't compile
Hi, seems that with https://cgit.freedesktop.org/libreoffice/core/commit/?id=b3c93b16d62e80955edc749af4b8ad10162c the new testTdf123870() won't compile ... /home/jenkins/workspace/libreoffice-upstream-bundled/label/mt-snow-02-brq/sc/qa/extras/scpdfexport.cxx: In member function ‘void ScPDFExportTest::testTdf123870()’: /home/jenkins/workspace/libreoffice-upstream-bundled/label/mt-snow-02-brq/sc/qa/extras/scpdfexport.cxx:399:5: error: ‘loadFromURL’ was not declared in this scope; did you mean ‘loadFromFile’? 399 | loadFromURL(u"tdf123870.ods"); | ^~~ | loadFromFile ... I think the compiler's suggestion is right. Thanks, Dan
Re: CppunitTest_vcl_text failing now
On Wed, 6 Dec 2023 11:32:42 +0100 Dan Horák wrote: > On Wed, 6 Dec 2023 11:22:46 +0100 > Dan Horák wrote: > > > Hi, > > > > seems that after a change from yesterday the CppunitTest_vcl_text test > > is failing now. Again this is in our CI with only system fonts being > > used. > > isn't #if HAVE_MORE_FONTS missing for testTdf107718()? thanks, Rene, for the MR :-) It's fixed now. Dan > > > Dan > > > 708e379994591c6e73f07bd2aba136841c9cf036 is good > > 24135dc15a797ca91dd32c70cbc4d26a05dfd127 is bad > > (not bisected yet) > > > > from the build log > > ... > > [_RUN_] testTdf107718::TestBody > > /home/sharkcz/projects/libreoffice/vcl/qa/cppunit/complextext.cxx:553:testTdf107718::TestBody > > assertion failed > > - Expression: pGlyphItem->glyphId() > > > > > > > > Thanks, > > > > Dan
Re: CppunitTest_vcl_text failing now
On Wed, 6 Dec 2023 11:22:46 +0100 Dan Horák wrote: > Hi, > > seems that after a change from yesterday the CppunitTest_vcl_text test > is failing now. Again this is in our CI with only system fonts being > used. isn't #if HAVE_MORE_FONTS missing for testTdf107718()? Dan > 708e379994591c6e73f07bd2aba136841c9cf036 is good > 24135dc15a797ca91dd32c70cbc4d26a05dfd127 is bad > (not bisected yet) > > from the build log > ... > [_RUN_] testTdf107718::TestBody > /home/sharkcz/projects/libreoffice/vcl/qa/cppunit/complextext.cxx:553:testTdf107718::TestBody > assertion failed > - Expression: pGlyphItem->glyphId() > > > > Thanks, > > Dan
CppunitTest_vcl_text failing now
Hi, seems that after a change from yesterday the CppunitTest_vcl_text test is failing now. Again this is in our CI with only system fonts being used. 708e379994591c6e73f07bd2aba136841c9cf036 is good 24135dc15a797ca91dd32c70cbc4d26a05dfd127 is bad (not bisected yet) from the build log ... [_RUN_] testTdf107718::TestBody /home/sharkcz/projects/libreoffice/vcl/qa/cppunit/complextext.cxx:553:testTdf107718::TestBody assertion failed - Expression: pGlyphItem->glyphId() Thanks, Dan
Re: CppunitTest_sw_txt{export,import} failing now
On Fri, 24 Nov 2023 16:04:08 +0100
Miklos Vajna wrote:
> Hi Dan,
>
> On Fri, Nov 24, 2023 at 03:47:26PM +0100, Dan Horák wrote:
> > seems that probably after
> > https://cgit.freedesktop.org/libreoffice/core/commit/?id=85852ad0d96bfd71413aef94edc1b6e2e6052e1a
> > (or some other change merged during yesterday) the
> > CppunitTest_sw_txt{export,import} tests are failing now in our CI with
> > system fonts being used.
>
> Yes, this will be probably the above commit.
>
> > (gdb) p rPattern.maTargetName
> > $1 = "DejaVu Sans"
> > (gdb) p rPattern.maSearchName
> > $2 = "Droid Sans Fallback"
> >
> > but the system has dejavu-sans-fonts.noarch installed, so not sure
> > what's going on.
>
> Is this a --without-fonts build?
yes, it is
> If so, could you try if putting
>
> ifneq ($(filter MORE_FONTS,$(BUILD_TYPE)),)
> ...
> endif
>
> around the 'call gb_CppunitTest_set_non_application_font_use' lines, and
> see if it helps?
yes, it does resolve the issue
Thanks,
Dan
> If so, I should fix up the above commit and do this for all the 4
> changed test suites.
>
> Thanks,
>
> Miklos
CppunitTest_sw_txt{export,import} failing now
Hi,
seems that probably after
https://cgit.freedesktop.org/libreoffice/core/commit/?id=85852ad0d96bfd71413aef94edc1b6e2e6052e1a
(or some other change merged during yesterday) the
CppunitTest_sw_txt{export,import} tests are failing now in our CI with
system fonts being used.
running under gdb reveals
...
testBullets::Import_Export finished in: 3969ms
[_RUN_] testClearingBreakExport::TestBody
private:factory/swriter:
testClearingBreakExport::TestBody finished in: 47ms
[_RUN_] testTdf120574_utf16lebom::Import_Export
file:///home/sharkcz/projects/libreoffice//sw/qa/extras/txtexport/data//UTF16LEBOMCRLF.txt:
[New Thread 0xdc9d2800 (LWP 777502)]
[Thread 0xdc9d2800 (LWP 777502) exited]
Thread 1 "cppunittester" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=281474842427424, signo=signo@entry=6,
no_tid=no_tid@entry=0) at pthread_kill.c:44
Downloading source file
/usr/src/debug/glibc-2.37-14.fc38.aarch64/nptl/pthread_kill.c
44return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO
(ret) : 0;
(gdb) where
#0 __pthread_kill_implementation (threadid=281474842427424,
signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0xf7960ae8 in __pthread_kill_internal (signo=6, threadid=) at pthread_kill.c:78
#2 0xf7914b40 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#3 0xf7900288 in __GI_abort () at abort.c:79
#4 0xe82c320c in
psp::PrintFontManager::Substitute(vcl::font::FontSelectPattern&,
rtl::OUString&) (this=0x14d4460, rPattern=..., rMissingCodes="")
at
/home/sharkcz/projects/libreoffice/vcl/unx/generic/fontmanager/fontconfig.cxx:1174
#5 0xe82bd1ac in GetFcSubstitute (rMissingCodes="", rFontSelData=...)
at
/home/sharkcz/projects/libreoffice/vcl/unx/generic/fontmanager/fontsubst.cxx:67
#6 (anonymous namespace)::FcGlyphFallbackSubstitution::FindFontSubstitute
(this=, rMissingCodes="", rFontSelData=...)
at
/home/sharkcz/projects/libreoffice/vcl/unx/generic/fontmanager/fontsubst.cxx:184
(gdb) p rPattern.maTargetName
$1 = "DejaVu Sans"
(gdb) p rPattern.maSearchName
$2 = "Droid Sans Fallback"
but the system has dejavu-sans-fonts.noarch installed, so not sure
what's going on.
Thanks,
Dan
build failure in cmis_content.cxx
Hi, our CI is getting a build failure in the master branch caused by change from yesterday ... In file included from /home/jenkins/workspace/libreoffice-upstream-bundled/label/mt-snow-02-brq/ucb/source/ucp/cmis/cmis_content.cxx:59: /home/jenkins/workspace/libreoffice-upstream-bundled/label/mt-snow-02-brq/include/curlinit.hxx: In function ‘void InitCurl_easy(CURL*)’: /home/jenkins/workspace/libreoffice-upstream-bundled/label/mt-snow-02-brq/include/curlinit.hxx:28:30: error: ‘GetCABundleFile’ was not declared in this scope 28 | char const* const path = GetCABundleFile(); | ^~~ 3aca2d9776a871f15009a1aa70628ba3a03ee147 is bad 0156cba6e34026f8fa0f2912e503378a5ec2208d is good (no bisecting yet) Is it a known issue? All libs except zlib, openssl and boost are bundled, "make distclean" before every build. Thanks, Dan
Re: new bridgetest failures in 7.6 on ppc64le
On Thu, 5 Oct 2023 17:46:13 +0200
Dan Horák wrote:
> On Thu, 5 Oct 2023 17:11:55 +0200
> Stephan Bergmann wrote:
>
> > 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, );
> >
> > 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.
> >
>
> thanks and for the record, with https://fedora.danny.cz/ppc/bridge-debug.patch
> I am getting https://fedora.danny.cz/ppc/bridge-debug.log after "make
> unitcheck"
> under testtools/
>
> You can see both the C++ and Java test running (IMO good for comparison)
> and when the struct is translated from Java to UNO, it still looks good
> (IMHO), search for "STRUCT top-level". Then the "f1" and "f2" prints from
> right after
> https://git.libreoffice.org/core/+/refs/heads/master/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx#218
> they are bad.
>
> I will look further especially at the dynamically generated stubs,
> which is new to me. Apply those stubs to the C++ bridge as well?
rough guess, but we might be missing something like
https://git.libreoffice.org/core/+/refs/heads/master/bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx#352
Dan
Re: new bridgetest failures in 7.6 on ppc64le
On Thu, 5 Oct 2023 17:11:55 +0200
Stephan Bergmann wrote:
> 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, );
>
> 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.
>
thanks and for the record, with https://fedora.danny.cz/ppc/bridge-debug.patch
I am getting https://fedora.danny.cz/ppc/bridge-debug.log after "make unitcheck"
under testtools/
You can see both the C++ and Java test running (IMO good for comparison)
and when the struct is translated from Java to UNO, it still looks good
(IMHO), search for "STRUCT top-level". Then the "f1" and "f2" prints from
right after
https://git.libreoffice.org/core/+/refs/heads/master/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx#218
they are bad.
I will look further especially at the dynamically generated stubs,
which is new to me. Apply those stubs to the C++ bridge as well?
Dan
Re: new bridgetest failures in 7.6 on ppc64le
On Thu, 31 Aug 2023 14:04:34 +0200 Stephan Bergmann wrote: > On 8/31/23 13:51, Dan Horák wrote: > > On Thu, 31 Aug 2023 10:21:05 +0200 > > Dan Horák 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... finally I can report some progress with this issue, although only with understanding what is going on. Seems to be another ABI issue, the resulting TwoFloat struct is returned back to performTest() [1] in a general purpose register (r3) as it would be a single "int64" value. It should be returned in floating point registers (f1, f2) as it is a homogeneous struct with float members. If I see right in my debugging, then it breaks in the last step when converting back from the UNO format to the native C++. The previous Java to UNO step looks OK to me. Is MapReturn() from the "cpp_uno" bridge [2] involved there? And I believe the same applies to the FourFloat struct test. 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 :-) [1] https://git.libreoffice.org/core/+/refs/heads/master/testtools/source/bridgetest/bridgetest.cxx#474 [2] https://git.libreoffice.org/core/+/refs/heads/master/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx#95 Thanks, Dan
[Libreoffice-commits] core.git: sw/qa
sw/qa/extras/globalfilter/globalfilter.cxx | 38 -
1 file changed, 21 insertions(+), 17 deletions(-)
New commits:
commit e03be024ae9c16fa8542757ad2c327259d5b9b0c
Author: Dan Horák
AuthorDate: Fri Sep 15 11:17:58 2023 +0200
Commit: Michael Stahl
CommitDate: Mon Sep 18 11:19:10 2023 +0200
sw/qa/extras/globalfilter: check for pdfium availability
A section of testListLabelPDFExport requires pdfium. The pPdfDocument
pointer
is set to NULL when pdfium is not available, so check it first. This
avoids a segfault when LO would be built without pdfium.
Change-Id: Ic66a4552c8512702bbfd6d24f5bb581ab824bbe0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156940
Reviewed-by: Michael Stahl
Tested-by: Jenkins
diff --git a/sw/qa/extras/globalfilter/globalfilter.cxx
b/sw/qa/extras/globalfilter/globalfilter.cxx
index 64bc2063beb1..3eb328f0b5cc 100644
--- a/sw/qa/extras/globalfilter/globalfilter.cxx
+++ b/sw/qa/extras/globalfilter/globalfilter.cxx
@@ -1286,23 +1286,27 @@ CPPUNIT_TEST_FIXTURE(Test, testListLabelPDFExport)
// Parse the export result with pdfium.
std::unique_ptr pPdfDocument = parsePDFExport();
-// The document has one page.
-CPPUNIT_ASSERT_EQUAL(1, pPdfDocument->getPageCount());
-std::unique_ptr pPdfPage =
pPdfDocument->openPage(/*nIndex=*/0);
-CPPUNIT_ASSERT(pPdfPage);
-
-std::unique_ptr pPdfTextPage =
pPdfPage->getTextPage();
-CPPUNIT_ASSERT(pPdfTextPage);
-
-int nChars = pPdfTextPage->countChars();
-CPPUNIT_ASSERT_EQUAL(22, nChars);
-
-// Check that the label strings were exported correctly
-std::vector aChars(nChars);
-for (int i = 0; i < nChars; i++)
-aChars[i] = pPdfTextPage->getUnicode(i);
-OUString aText(aChars.data(), aChars.size());
-
CPPUNIT_ASSERT_EQUAL(OUString(u"\u0623\r\n.\r\n\u0623.\u0623\r\n.\r\n\u0623.\u0623.\u0623\r\n."),
aText);
+// Non-NULL pPdfDocument means pdfium is available.
+if (pPdfDocument != nullptr)
+{
+// The document has one page.
+CPPUNIT_ASSERT_EQUAL(1, pPdfDocument->getPageCount());
+std::unique_ptr pPdfPage =
pPdfDocument->openPage(/*nIndex=*/0);
+CPPUNIT_ASSERT(pPdfPage);
+
+std::unique_ptr pPdfTextPage =
pPdfPage->getTextPage();
+CPPUNIT_ASSERT(pPdfTextPage);
+
+int nChars = pPdfTextPage->countChars();
+CPPUNIT_ASSERT_EQUAL(22, nChars);
+
+// Check that the label strings were exported correctly
+std::vector aChars(nChars);
+for (int i = 0; i < nChars; i++)
+aChars[i] = pPdfTextPage->getUnicode(i);
+OUString aText(aChars.data(), aChars.size());
+
CPPUNIT_ASSERT_EQUAL(OUString(u"\u0623\r\n.\r\n\u0623.\u0623\r\n.\r\n\u0623.\u0623.\u0623\r\n."),
aText);
+}
// Parse the document again to get its raw content
// TODO: get the content from PDFiumPage somehow
Re: MAKEFLAGS ignored?
On Fri, 15 Sep 2023 11:11:29 +0200 Michael Stahl wrote: > hi Dan, > > On 07/09/2023 13:36, Dan Horák wrote: > > Hello, > > > > I was trying to pass the "--keep-going" option to the Makefile via the > > MAKEFLAGS [1] to get as much test failures as possible in a single run, > > but it seems to be ignored. After reading the make manual for the value > > function [2], I think GMAKE_OPTIONS definition should rather look like > > > > -export GMAKE_OPTIONS?=-r$(if $(verbose),,s)$(value $(MAKEFLAGS)) > > +export GMAKE_OPTIONS?=-r$(if $(verbose),,s) $(value MAKEFLAGS) > > > > What do you think? > > this looks rather odd indeed, and i guess you're the first person to try > setting MAKEFLAGS manually. > > probably it's best to change it as you suggest. ok, https://gerrit.libreoffice.org/c/core/+/156942 then :-) Dan
Re: testListLabelPDFExport segfaulting
On Thu, 14 Sep 2023 10:50:35 +0200 Stephan Bergmann wrote: > On 9/14/23 09:44, Dan Horák wrote: > > On Thu, 14 Sep 2023 09:16:38 +0200 > > Stephan Bergmann wrote: > >> I'd suggest to rather make execution of the test dependent on > >> $(ENABLE_PDFIUM), or on PDFIUM in $(BUILD_TYPE) (cf. configure.ac). > >> (Otherwise, you would silently hide errors when parsePDFExport() > >> erroneously returns null.) > > > > if I read > > https://opengrok.libreoffice.org/xref/core/test/source/unoapi_test.cxx?r=58ab2f00#213 > > right, then parsePDFExport() can return NULL only when built without > > pdfium. There is an assert checking NULL value returned from > > pPDFium->openDocument(). Thus we shouldn't be hiding anything, I > > believe. > > Yeah, it can only return null when vcl::pdf::PDFiumLibrary::get() > returns null. Which in turn can only happen when that uses > vcl/source/pdf/DummyPDFiumLibrary.cxx rather than > vcl/source/pdf/PDFiumLibrary.cxx. A bit of an indirection, so I guess I > would still use the explicit $(ENABLE_PDFIUM) way, but of course leave > it up to you. I went with the runtime check [1], using the $(ENABLE_PDFIUM) on the Makefile level we would lose the whole CppunitTest_sw_globalfilter and there is not HAVE_PDFIUM define to exclude the testListLabelPDFExport. [1] https://gerrit.libreoffice.org/c/core/+/156940 Dan
Re: testListLabelPDFExport segfaulting
On Thu, 14 Sep 2023 09:16:38 +0200 Stephan Bergmann wrote: > On 9/13/23 23:17, Dan Horák wrote: > > ... > > [New Thread 0x7fffcb38e7a0 (LWP 2839768)] > > [Thread 0x7fffcb38e7a0 (LWP 2839768) exited] > > warn:legacy.osl:2838662:2838662:oox/source/helper/storagebase.cxx:67: > > StorageBase::StorageBase - missing base input stream > > Test::testDateFormFieldCharacterFormatting finished in: 5248ms > > [_RUN_] testListLabelPDFExport::TestBody > > private:factory/swriter: > > > > Thread 1 "cppunittester" received signal SIGSEGV, Segmentation fault. > > 0x7fffd7c16188 in testListLabelPDFExport::TestBody (this=0x10e6d640) at > > /home/sharkcz/projects/libreoffice/sw/qa/extras/globalfilter/globalfilter.cxx:1290 > > 1290CPPUNIT_ASSERT_EQUAL(1, pPdfDocument->getPageCount()); > > (gdb) where > > #0 0x7fffd7c16188 in testListLabelPDFExport::TestBody() > > (this=0x10e6d640) at > > /home/sharkcz/projects/libreoffice/sw/qa/extras/globalfilter/globalfilter.cxx:1290 > > #1 0x7fffd7c9b4a8 in std::__invoke_impl > (testListLabelPDFExport::*&)(), > > testListLabelPDFExport*&>(std::__invoke_memfun_deref, void > > (testListLabelPDFExport::*&)(), testListLabelPDFExport*&) (__f=@0x10e6dba0: > > (void (testListLabelPDFExport::*)(testListLabelPDFExport * const)) > > 0x7fffd7c155d8 , __t=@0x10e6dbb0: > > 0x10e6d640) > > at /usr/include/c++/13/bits/invoke.h:74 > > ... > > > > but I think I see the problem, pPdfDocument is NULL, which is returned > > by parsePDFExport(), because we don't build with pdfium, I suppose. > > I can prepare a patch to run the test section only when non-NULL. > > I'd suggest to rather make execution of the test dependent on > $(ENABLE_PDFIUM), or on PDFIUM in $(BUILD_TYPE) (cf. configure.ac). > (Otherwise, you would silently hide errors when parsePDFExport() > erroneously returns null.) if I read https://opengrok.libreoffice.org/xref/core/test/source/unoapi_test.cxx?r=58ab2f00#213 right, then parsePDFExport() can return NULL only when built without pdfium. There is an assert checking NULL value returned from pPDFium->openDocument(). Thus we shouldn't be hiding anything, I believe. > But I wonder why all the other tests that call parsePDFExport() don't > appear to be conditional on $(ENABLE_PDFIUM), either. > Dan
Re: testListLabelPDFExport segfaulting
On Wed, 13 Sep 2023 22:02:49 +0200 Noel Grandin wrote: > A debug build (--enable-debug) would possibly give a more useful backtrace. bisecting shows https://git.libreoffice.org/core/+/ea0f9776ed8e7e9809853d292923b86756274564 is the first bad commit the better backtrace is here ... [New Thread 0x7fffcb38e7a0 (LWP 2839768)] [Thread 0x7fffcb38e7a0 (LWP 2839768) exited] warn:legacy.osl:2838662:2838662:oox/source/helper/storagebase.cxx:67: StorageBase::StorageBase - missing base input stream Test::testDateFormFieldCharacterFormatting finished in: 5248ms [_RUN_] testListLabelPDFExport::TestBody private:factory/swriter: Thread 1 "cppunittester" received signal SIGSEGV, Segmentation fault. 0x7fffd7c16188 in testListLabelPDFExport::TestBody (this=0x10e6d640) at /home/sharkcz/projects/libreoffice/sw/qa/extras/globalfilter/globalfilter.cxx:1290 1290CPPUNIT_ASSERT_EQUAL(1, pPdfDocument->getPageCount()); (gdb) where #0 0x7fffd7c16188 in testListLabelPDFExport::TestBody() (this=0x10e6d640) at /home/sharkcz/projects/libreoffice/sw/qa/extras/globalfilter/globalfilter.cxx:1290 #1 0x7fffd7c9b4a8 in std::__invoke_impl(std::__invoke_memfun_deref, void (testListLabelPDFExport::*&)(), testListLabelPDFExport*&) (__f=@0x10e6dba0: (void (testListLabelPDFExport::*)(testListLabelPDFExport * const)) 0x7fffd7c155d8 , __t=@0x10e6dbb0: 0x10e6d640) at /usr/include/c++/13/bits/invoke.h:74 ... but I think I see the problem, pPdfDocument is NULL, which is returned by parsePDFExport(), because we don't build with pdfium, I suppose. I can prepare a patch to run the test section only when non-NULL. Dan
Re: recent KahanSum change causes a new test failure on ppc64le
On Wed, 13 Sep 2023 13:06:10 +0200
Eike Rathke wrote:
> Hi,
>
> On Thursday, 2023-09-07 11:36:33 +0200, Stephan Bergmann wrote:
>
> > On 9/7/23 08:25, Dan Horák wrote:
> > > On Thu, 7 Sep 2023 08:16:28 +0200
> > > Stephan Bergmann wrote:
> > > > On 9/5/23 18:53, Dan Horák wrote:
> > > > > seems the recent change [1] to KahanSum handling causes a test failure
> > > > > on ppc64le.
> > > > >
> > > > > Running scope as unit:
> > > > > -home-sharkcz-projects-libreoffice-workdir-CppunitTest-sc_statistical_functions_test.test:20230905152639:2378561.scope
> > > > > [_RUN_] StatisticalFunctionsTest::testStatisticalFormulasFODS
> > > > > Testing load
> > > > > file:///home/sharkcz/projects/libreoffice//sc/qa/unit/data/functions/statistical/fods/KahanSum.fods:
> > > > > /home/sharkcz/projects/libreoffice/sc/qa/unit/functions_test.cxx:49:StatisticalFunctionsTest::testStatisticalFormulasFODS
> > > > > forced failure
> > > > > - Testing
> > > > > file:///home/sharkcz/projects/libreoffice//sc/qa/unit/data/functions/statistical/fods/KahanSum.fods
> > > > > failed, Sheet2.A90 '=SUM(F3:F102)' result: 6.6, expected: 5
> > > >
> > > > Interesting; I also saw that failure with my latest local build on macOS
> > > > aarch64 against Clang trunk. (But didn't debug it further and wrote it
> > > > off as maybe some intermittent Clang trunk bug.)
> > > >
> > >
> > > someone on IRC reported the same issue, also from macOS I believe
> >
> > So, wild speculation, maybe it's a difference between x86-64 and all other
> > architectures, given how that
> > <https://gerrit.libreoffice.org/c/core/+/156253/> "Resolves: tdf#156985
> > Treat adding two KahanSum differently" kept failing for (32-bit)
> > <https://ci.libreoffice.org/job/gerrit_windows/> up until patch set 7. (And
> > where patch set 8 reverted back to the original code for _WIN32, maybe in a
> > misguided attempt to fix something that was seen failing on Windows 32-bit
> > x86, but not known to (not) fail on Windows x86-64.)
> >
> > Eike, any thoughts?
>
> Hum.. seeing there's platform specific code in
> sc/inc/arraysumfunctor.hxx executeFast() that for
> #if defined(X86_64) || (defined(X86) && defined(_WIN32))
> calls executeSSE2() (implemented in
> sc/source/core/tool/arraysumSSE2.cxx) and for others executeUnrolled(),
> I wonder if we never have X86 defined and thus the _WIN32 fails as well
> with executeUnrolled() and that "unrolled pair-wise" algorithm has
> a flaw.
>
> It would be worth a try to simply call executeFast() only if SC_USE_SSE2
> is defined, so the failing platforms skip executeUnrolled(), here
> https://opengrok.libreoffice.org/xref/core/sc/inc/arraysumfunctor.hxx?r=7f15354c#89
>
> Please report back if that helps and I'll prepare another patch.
I hop I got your idea right and with
diff --git a/sc/inc/arraysumfunctor.hxx b/sc/inc/arraysumfunctor.hxx
index c261c120addf..d9a5b805db50 100644
--- a/sc/inc/arraysumfunctor.hxx
+++ b/sc/inc/arraysumfunctor.hxx
@@ -86,7 +86,11 @@ inline KahanSum sumArray(const double* pArray, size_t nSize)
{
size_t i = 0;
const double* pCurrent = pArray;
+#if 0
KahanSum fSum = executeFast(i, nSize, pCurrent);
+#else
+KahanSum fSum = 0.0;
+#endif
// sum rest of the array
for (; i < nSize; ++i)
the test passed on aarch64 on master branch (no reverts or such)
Dan
testListLabelPDFExport segfaulting
Hello,
we are seeing segfaults in the testListLabelPDFExport from
CppunitTest_sw_globalfilter at least on aarch64 and ppc64le in Fedora.
To some degree it's related to
https://git.libreoffice.org/core/+/ea0f9776ed8e7e9809853d292923b86756274564
because reverting the commit removes the segfault, but the test still
fails on some assert. The 7-6-branching-point has no such issue.
...
[Thread 0x7fffd2a0e7a0 (LWP 2064868) exited]
Test::testDateFormFieldCharacterFormatting finished in: 1481ms
[_RUN_] testListLabelPDFExport::TestBody
private:factory/swriter:
Thread 1 "cppunittester" received signal SIGSEGV, Segmentation fault.
testListLabelPDFExport::TestBody (this=0x102a95d0) at
/usr/include/c++/13/bits/unique_ptr.h:199
199 pointer_M_ptr() const noexcept { return std::get<0>(_M_t); }
(gdb) where
#0 testListLabelPDFExport::TestBody() (this=0x102a95d0) at
/usr/include/c++/13/bits/unique_ptr.h:199
#1 0x7fffdc9aaf4c in std::__invoke_impl(std::__invoke_memfun_deref, void
(testListLabelPDFExport::*&)(), testListLabelPDFExport*&) (__f=,
__t=) at /usr/include/c++/13/bits/invoke.h:71
#2 std::__invoke(void (testListLabelPDFExport::*&)(),
testListLabelPDFExport*&) (__fn=)
at /usr/include/c++/13/bits/invoke.h:96
#3 std::_Bind::__call(std::tuple<>&&, std::_Index_tuple<0ul>) (__args=,
this=)
at /usr/include/c++/13/functional:506
#4 std::_Bind::operator()<, void>()
(this=) at /usr/include/c++/13/functional:591
#5 std::__invoke_impl&>(std::__invoke_other,
std::_Bind&)
(__f=) at /usr/include/c++/13/bits/invoke.h:61
#6 std::__invoke_r&>(std::_Bind&)
(__fn=) at /usr/include/c++/13/bits/invoke.h:111
#7 std::_Function_handler
>::_M_invoke(std::_Any_data const&) (__functor=)
at /usr/include/c++/13/bits/std_function.h:290
#8 0x7fffdc9ab424 in std::function::operator()() const
(this=) at /usr/include/c++/13/bits/std_function.h:591
#9 CppUnit::TestCaller::runTest() (this=)
at
/home/sharkcz/projects/libreoffice/workdir/UnpackedTarball/cppunit/include/cppunit/TestCaller.h:175
#10 0x77ebc578 in CppUnit::TestCaseMethodFunctor::operator()() const ()
at
/home/sharkcz/projects/libreoffice/workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.15.so.1
#11 0x7fffdd0102fc in (anonymous
namespace)::Protector::protect(CppUnit::Functor const&,
CppUnit::ProtectorContext const&) (this=, functor=)
at
/home/sharkcz/projects/libreoffice/test/source/vclbootstrapprotector.cxx:46
#12 0x77eb303c in CppUnit::ProtectorChain::ProtectFunctor::operator()()
const ()
at
/home/sharkcz/projects/libreoffice/workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.15.so.1
#13 0x7fffe9a5067c in (anonymous namespace)::Prot::protect(CppUnit::Functor
const&, CppUnit::ProtectorContext const&) (this=,
functor=)
at
/home/sharkcz/projects/libreoffice/unotest/source/cpp/unobootstrapprotector/unobootstrapprotector.cxx:78
#14 0x77eb303c in CppUnit::ProtectorChain::ProtectFunctor::operator()()
const ()
at
/home/sharkcz/projects/libreoffice/workdir/UnpackedTarball/cppunit/src/cppunit/.libs/libcppunit-1.15.so.1
Dan
Re: recent KahanSum change causes a new test failure on ppc64le
On Thu, 7 Sep 2023 11:36:33 +0200 Stephan Bergmann wrote: > On 9/7/23 08:25, Dan Horák wrote: > > On Thu, 7 Sep 2023 08:16:28 +0200 > > Stephan Bergmann wrote: > >> On 9/5/23 18:53, Dan Horák wrote: > >>> seems the recent change [1] to KahanSum handling causes a test failure > >>> on ppc64le. > >>> > >>> Running scope as unit: > >>> -home-sharkcz-projects-libreoffice-workdir-CppunitTest-sc_statistical_functions_test.test:20230905152639:2378561.scope > >>> [_RUN_] StatisticalFunctionsTest::testStatisticalFormulasFODS > >>> Testing load > >>> file:///home/sharkcz/projects/libreoffice//sc/qa/unit/data/functions/statistical/fods/KahanSum.fods: > >>> /home/sharkcz/projects/libreoffice/sc/qa/unit/functions_test.cxx:49:StatisticalFunctionsTest::testStatisticalFormulasFODS > >>> forced failure > >>> - Testing > >>> file:///home/sharkcz/projects/libreoffice//sc/qa/unit/data/functions/statistical/fods/KahanSum.fods > >>> failed, Sheet2.A90 '=SUM(F3:F102)' result: 6.6, expected: 5 > >> > >> Interesting; I also saw that failure with my latest local build on macOS > >> aarch64 against Clang trunk. (But didn't debug it further and wrote it > >> off as maybe some intermittent Clang trunk bug.) > >> > > > > someone on IRC reported the same issue, also from macOS I believe > > So, wild speculation, maybe it's a difference between x86-64 and all > other architectures, given how that > <https://gerrit.libreoffice.org/c/core/+/156253/> "Resolves: tdf#156985 > Treat adding two KahanSum differently" kept failing for (32-bit) > <https://ci.libreoffice.org/job/gerrit_windows/> up until patch set 7. > (And where patch set 8 reverted back to the original code for _WIN32, > maybe in a misguided attempt to fix something that was seen failing on > Windows 32-bit x86, but not known to (not) fail on Windows x86-64.) > > Eike, any thoughts? > and for the record, I have just confirmed Fedora aarch64 and s390x systems have the same issue Dan
[Libreoffice-commits] core.git: Branch 'libreoffice-7-5' - bridges/source
bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx | 58 ++--
1 file changed, 52 insertions(+), 6 deletions(-)
New commits:
commit ea81248b892f539651a880e16ad865cf99b67070
Author: Dan Horák
AuthorDate: Tue Sep 12 10:20:51 2023 +0200
Commit: Stephan Bergmann
CommitDate: Wed Sep 13 08:37:38 2023 +0200
bridge/powerpc64: fix integer ABI
The ABI document for PowerPC64 specifies that integer values shorter than
a doubleword are sign or zero extended as necessary. Until now the smaller
values were treated as unsigned values and only zero-extended. Handling of
signed values was incorrect.
Change-Id: Icbbe8fc8d4facfa6d1b3252c99ec2d8c2552d9f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156847
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann
(cherry picked from commit 0effeef3dc952959af50c045514bbcd135c37fb7)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156873
diff --git a/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx
b/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx
index 612495d83395..9b66f778dfd6 100644
--- a/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx
+++ b/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx
@@ -256,6 +256,14 @@ static void callVirtualMethod(void * pThis, sal_uInt32
nVtableIndex,
*pDS++ = *reinterpret_cast( pSV ); // verbatim!
#define INSERT_INT64( pSV, nr, pGPR, pDS, bOverflow ) \
+if ( nr < ppc64::MAX_GPR_REGS ) \
+pGPR[nr++] = *reinterpret_cast( pSV ); \
+else \
+bOverflow = true; \
+if (bOverflow) \
+*pDS++ = *reinterpret_cast( pSV );
+
+#define INSERT_UINT64( pSV, nr, pGPR, pDS, bOverflow ) \
if ( nr < ppc64::MAX_GPR_REGS ) \
pGPR[nr++] = *reinterpret_cast( pSV ); \
else \
@@ -264,6 +272,14 @@ static void callVirtualMethod(void * pThis, sal_uInt32
nVtableIndex,
*pDS++ = *reinterpret_cast( pSV );
#define INSERT_INT32( pSV, nr, pGPR, pDS, bOverflow ) \
+if ( nr < ppc64::MAX_GPR_REGS ) \
+pGPR[nr++] = *reinterpret_cast( pSV ); \
+else \
+bOverflow = true; \
+if (bOverflow) \
+*pDS++ = *reinterpret_cast( pSV );
+
+#define INSERT_UINT32( pSV, nr, pGPR, pDS, bOverflow ) \
if ( nr < ppc64::MAX_GPR_REGS ) \
pGPR[nr++] = *reinterpret_cast( pSV ); \
else \
@@ -272,6 +288,14 @@ static void callVirtualMethod(void * pThis, sal_uInt32
nVtableIndex,
*pDS++ = *reinterpret_cast( pSV );
#define INSERT_INT16( pSV, nr, pGPR, pDS, bOverflow ) \
+if ( nr < ppc64::MAX_GPR_REGS ) \
+pGPR[nr++] = *reinterpret_cast( pSV ); \
+else \
+bOverflow = true; \
+if (bOverflow) \
+*pDS++ = *reinterpret_cast( pSV );
+
+#define INSERT_UINT16( pSV, nr, pGPR, pDS, bOverflow ) \
if ( nr < ppc64::MAX_GPR_REGS ) \
pGPR[nr++] = *reinterpret_cast( pSV ); \
else \
@@ -280,6 +304,14 @@ static void callVirtualMethod(void * pThis, sal_uInt32
nVtableIndex,
*pDS++ = *reinterpret_cast( pSV );
#define INSERT_INT8( pSV, nr, pGPR, pDS, bOverflow ) \
+if ( nr < ppc64::MAX_GPR_REGS ) \
+pGPR[nr++] = *reinterpret_cast( pSV ); \
+else \
+bOverflow = true; \
+if (bOverflow) \
+*pDS++ = *reinterpret_cast( pSV );
+
+#define INSERT_UINT8( pSV, nr, pGPR, pDS, bOverflow ) \
if ( nr < ppc64::MAX_GPR_REGS ) \
pGPR[nr++] = *reinterpret_cast( pSV ); \
else \
@@ -335,7 +367,7 @@ static void cpp_call(
#if OSL_DEBUG_LEVEL > 2
fprintf(stderr, "pCppReturn/pUnoReturn is %lx/%lx", pCppReturn,
pUnoReturn);
#endif
-INSERT_INT64( , nGPR, pGPR, pStack, bOverflow );
+INSERT_UINT64( , nGPR, pGPR, pStack, bOverflow );
}
}
// push "this" pointer
@@ -343,7 +375,7 @@ static void cpp_call(
#if OSL_DEBUG_LEVEL > 2
fprintf(stderr, "this pointer is %p\n", pAdjustedThisPtr);
#endif
-INSERT_INT64( , nGPR, pGPR, pStack, bOverflow );
+INSERT_UINT64( , nGPR, pGPR, pStack, bOverflow );
// Args
void ** pCppArgs = (void **)alloca( 3 * sizeof(void *) * nParams );
@@ -376,26 +408,40 @@ static void cpp_call(
switch (pParamTypeDescr->eTypeClass)
{
case typelib_TypeClass_HYPER:
-case typelib_TypeClass_UNSIGNED_HYPER:
#if OSL_DEBUG_LEVEL > 2
fprintf(stderr, "hyper is %lx\n",
pCppArgs[nPos]);
#endif
INSERT_INT64( pCppArgs[nPos], nGPR, pGPR,
pStack, bOverflow );
break;
+
[Libreoffice-commits] core.git: Branch 'libreoffice-7-6' - bridges/source
bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx | 58 ++--
1 file changed, 52 insertions(+), 6 deletions(-)
New commits:
commit 5eec820938266ea862b7a23ae61f441f191669fc
Author: Dan Horák
AuthorDate: Tue Sep 12 10:20:51 2023 +0200
Commit: Stephan Bergmann
CommitDate: Wed Sep 13 08:24:28 2023 +0200
bridge/powerpc64: fix integer ABI
The ABI document for PowerPC64 specifies that integer values shorter than
a doubleword are sign or zero extended as necessary. Until now the smaller
values were treated as unsigned values and only zero-extended. Handling of
signed values was incorrect.
Change-Id: Icbbe8fc8d4facfa6d1b3252c99ec2d8c2552d9f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156847
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann
(cherry picked from commit 6d24e32d0278e1e71cbd1bfdc16899659e47b2a2)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156874
diff --git a/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx
b/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx
index 612495d83395..9b66f778dfd6 100644
--- a/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx
+++ b/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx
@@ -256,6 +256,14 @@ static void callVirtualMethod(void * pThis, sal_uInt32
nVtableIndex,
*pDS++ = *reinterpret_cast( pSV ); // verbatim!
#define INSERT_INT64( pSV, nr, pGPR, pDS, bOverflow ) \
+if ( nr < ppc64::MAX_GPR_REGS ) \
+pGPR[nr++] = *reinterpret_cast( pSV ); \
+else \
+bOverflow = true; \
+if (bOverflow) \
+*pDS++ = *reinterpret_cast( pSV );
+
+#define INSERT_UINT64( pSV, nr, pGPR, pDS, bOverflow ) \
if ( nr < ppc64::MAX_GPR_REGS ) \
pGPR[nr++] = *reinterpret_cast( pSV ); \
else \
@@ -264,6 +272,14 @@ static void callVirtualMethod(void * pThis, sal_uInt32
nVtableIndex,
*pDS++ = *reinterpret_cast( pSV );
#define INSERT_INT32( pSV, nr, pGPR, pDS, bOverflow ) \
+if ( nr < ppc64::MAX_GPR_REGS ) \
+pGPR[nr++] = *reinterpret_cast( pSV ); \
+else \
+bOverflow = true; \
+if (bOverflow) \
+*pDS++ = *reinterpret_cast( pSV );
+
+#define INSERT_UINT32( pSV, nr, pGPR, pDS, bOverflow ) \
if ( nr < ppc64::MAX_GPR_REGS ) \
pGPR[nr++] = *reinterpret_cast( pSV ); \
else \
@@ -272,6 +288,14 @@ static void callVirtualMethod(void * pThis, sal_uInt32
nVtableIndex,
*pDS++ = *reinterpret_cast( pSV );
#define INSERT_INT16( pSV, nr, pGPR, pDS, bOverflow ) \
+if ( nr < ppc64::MAX_GPR_REGS ) \
+pGPR[nr++] = *reinterpret_cast( pSV ); \
+else \
+bOverflow = true; \
+if (bOverflow) \
+*pDS++ = *reinterpret_cast( pSV );
+
+#define INSERT_UINT16( pSV, nr, pGPR, pDS, bOverflow ) \
if ( nr < ppc64::MAX_GPR_REGS ) \
pGPR[nr++] = *reinterpret_cast( pSV ); \
else \
@@ -280,6 +304,14 @@ static void callVirtualMethod(void * pThis, sal_uInt32
nVtableIndex,
*pDS++ = *reinterpret_cast( pSV );
#define INSERT_INT8( pSV, nr, pGPR, pDS, bOverflow ) \
+if ( nr < ppc64::MAX_GPR_REGS ) \
+pGPR[nr++] = *reinterpret_cast( pSV ); \
+else \
+bOverflow = true; \
+if (bOverflow) \
+*pDS++ = *reinterpret_cast( pSV );
+
+#define INSERT_UINT8( pSV, nr, pGPR, pDS, bOverflow ) \
if ( nr < ppc64::MAX_GPR_REGS ) \
pGPR[nr++] = *reinterpret_cast( pSV ); \
else \
@@ -335,7 +367,7 @@ static void cpp_call(
#if OSL_DEBUG_LEVEL > 2
fprintf(stderr, "pCppReturn/pUnoReturn is %lx/%lx", pCppReturn,
pUnoReturn);
#endif
-INSERT_INT64( , nGPR, pGPR, pStack, bOverflow );
+INSERT_UINT64( , nGPR, pGPR, pStack, bOverflow );
}
}
// push "this" pointer
@@ -343,7 +375,7 @@ static void cpp_call(
#if OSL_DEBUG_LEVEL > 2
fprintf(stderr, "this pointer is %p\n", pAdjustedThisPtr);
#endif
-INSERT_INT64( , nGPR, pGPR, pStack, bOverflow );
+INSERT_UINT64( , nGPR, pGPR, pStack, bOverflow );
// Args
void ** pCppArgs = (void **)alloca( 3 * sizeof(void *) * nParams );
@@ -376,26 +408,40 @@ static void cpp_call(
switch (pParamTypeDescr->eTypeClass)
{
case typelib_TypeClass_HYPER:
-case typelib_TypeClass_UNSIGNED_HYPER:
#if OSL_DEBUG_LEVEL > 2
fprintf(stderr, "hyper is %lx\n",
pCppArgs[nPos]);
#endif
INSERT_INT64( pCppArgs[nPos], nGPR, pGPR,
pStack, bOverflow );
break;
+
[Libreoffice-commits] core.git: bridges/source
bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx | 58 ++--
1 file changed, 52 insertions(+), 6 deletions(-)
New commits:
commit 6d24e32d0278e1e71cbd1bfdc16899659e47b2a2
Author: Dan Horák
AuthorDate: Tue Sep 12 10:20:51 2023 +0200
Commit: Stephan Bergmann
CommitDate: Tue Sep 12 19:42:54 2023 +0200
bridge/powerpc64: fix integer ABI
The ABI document for PowerPC64 specifies that integer values shorter than
a doubleword are sign or zero extended as necessary. Until now the smaller
values were treated as unsigned values and only zero-extended. Handling of
signed values was incorrect.
Change-Id: Icbbe8fc8d4facfa6d1b3252c99ec2d8c2552d9f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156847
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann
diff --git a/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx
b/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx
index 4bb4270806b8..37d75659fdb6 100644
--- a/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx
+++ b/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx
@@ -256,6 +256,14 @@ static void callVirtualMethod(void * pThis, sal_uInt32
nVtableIndex,
*pDS++ = *reinterpret_cast( pSV ); // verbatim!
#define INSERT_INT64( pSV, nr, pGPR, pDS, bOverflow ) \
+if ( nr < ppc64::MAX_GPR_REGS ) \
+pGPR[nr++] = *reinterpret_cast( pSV ); \
+else \
+bOverflow = true; \
+if (bOverflow) \
+*pDS++ = *reinterpret_cast( pSV );
+
+#define INSERT_UINT64( pSV, nr, pGPR, pDS, bOverflow ) \
if ( nr < ppc64::MAX_GPR_REGS ) \
pGPR[nr++] = *reinterpret_cast( pSV ); \
else \
@@ -264,6 +272,14 @@ static void callVirtualMethod(void * pThis, sal_uInt32
nVtableIndex,
*pDS++ = *reinterpret_cast( pSV );
#define INSERT_INT32( pSV, nr, pGPR, pDS, bOverflow ) \
+if ( nr < ppc64::MAX_GPR_REGS ) \
+pGPR[nr++] = *reinterpret_cast( pSV ); \
+else \
+bOverflow = true; \
+if (bOverflow) \
+*pDS++ = *reinterpret_cast( pSV );
+
+#define INSERT_UINT32( pSV, nr, pGPR, pDS, bOverflow ) \
if ( nr < ppc64::MAX_GPR_REGS ) \
pGPR[nr++] = *reinterpret_cast( pSV ); \
else \
@@ -272,6 +288,14 @@ static void callVirtualMethod(void * pThis, sal_uInt32
nVtableIndex,
*pDS++ = *reinterpret_cast( pSV );
#define INSERT_INT16( pSV, nr, pGPR, pDS, bOverflow ) \
+if ( nr < ppc64::MAX_GPR_REGS ) \
+pGPR[nr++] = *reinterpret_cast( pSV ); \
+else \
+bOverflow = true; \
+if (bOverflow) \
+*pDS++ = *reinterpret_cast( pSV );
+
+#define INSERT_UINT16( pSV, nr, pGPR, pDS, bOverflow ) \
if ( nr < ppc64::MAX_GPR_REGS ) \
pGPR[nr++] = *reinterpret_cast( pSV ); \
else \
@@ -280,6 +304,14 @@ static void callVirtualMethod(void * pThis, sal_uInt32
nVtableIndex,
*pDS++ = *reinterpret_cast( pSV );
#define INSERT_INT8( pSV, nr, pGPR, pDS, bOverflow ) \
+if ( nr < ppc64::MAX_GPR_REGS ) \
+pGPR[nr++] = *reinterpret_cast( pSV ); \
+else \
+bOverflow = true; \
+if (bOverflow) \
+*pDS++ = *reinterpret_cast( pSV );
+
+#define INSERT_UINT8( pSV, nr, pGPR, pDS, bOverflow ) \
if ( nr < ppc64::MAX_GPR_REGS ) \
pGPR[nr++] = *reinterpret_cast( pSV ); \
else \
@@ -339,7 +371,7 @@ static void cpp_call(
#if OSL_DEBUG_LEVEL > 2
fprintf(stderr, "pCppReturn/pUnoReturn is %p/%p\n", pCppReturn,
pUnoReturn);
#endif
-INSERT_INT64( , nGPR, pGPR, pStack, bOverflow );
+INSERT_UINT64( , nGPR, pGPR, pStack, bOverflow );
}
}
// push "this" pointer
@@ -347,7 +379,7 @@ static void cpp_call(
#if OSL_DEBUG_LEVEL > 2
fprintf(stderr, "this pointer is %p\n", pAdjustedThisPtr);
#endif
-INSERT_INT64( , nGPR, pGPR, pStack, bOverflow );
+INSERT_UINT64( , nGPR, pGPR, pStack, bOverflow );
// Args
void ** pCppArgs = (void **)alloca( 3 * sizeof(void *) * nParams );
@@ -380,26 +412,40 @@ static void cpp_call(
switch (pParamTypeDescr->eTypeClass)
{
case typelib_TypeClass_HYPER:
-case typelib_TypeClass_UNSIGNED_HYPER:
#if OSL_DEBUG_LEVEL > 2
fprintf(stderr, "hyper is 0x%lx\n",
*(sal_Int64 *)pCppArgs[nPos]);
#endif
INSERT_INT64( pCppArgs[nPos], nGPR, pGPR,
pStack, bOverflow );
break;
+case typelib_TypeClass_UNSIGNED_HYPER:
+#if OSL_DEBUG_LEVEL > 2
+
[Libreoffice-commits] core.git: bridges/source
bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx | 20 +---
1 file changed, 12 insertions(+), 8 deletions(-)
New commits:
commit f171d5cb322ed99b3c4cd6c0b18abbf03882ec98
Author: Dan Horák
AuthorDate: Tue Sep 12 10:04:47 2023 +0200
Commit: Stephan Bergmann
CommitDate: Tue Sep 12 17:46:49 2023 +0200
bridge: modernize printf debugging in powerpc64
Use correct types and also typecasts to avoid compiler warnings.
Change-Id: I3b58ec6a4be54ecd8bc07a7febbaf721eba9b945
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156846
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann
diff --git a/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx
b/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx
index 612495d83395..4bb4270806b8 100644
--- a/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx
+++ b/bridges/source/cpp_uno/gcc3_linux_powerpc64/uno2cpp.cxx
@@ -161,13 +161,13 @@ static void callVirtualMethod(void * pThis, sal_uInt32
nVtableIndex,
// Let's figure out what is really going on here
{
fprintf( stderr, "= callVirtualMethod() =\nGPR's (%d): ", nGPR
);
-for ( int i = 0; i < nGPR; ++i )
+for ( sal_uInt32 i = 0; i < nGPR; ++i )
fprintf( stderr, "0x%lx, ", pGPR[i] );
fprintf( stderr, "\nFPR's (%d): ", nFPR );
-for ( int i = 0; i < nFPR; ++i )
-fprintf( stderr, "0x%lx (%f), ", pFPR[i], pFPR[i] );
+for ( sal_uInt32 i = 0; i < nFPR; ++i )
+fprintf( stderr, "0x%lx (%lf), ", (sal_Int64)pFPR[i],
pFPR[i] );
fprintf( stderr, "\nStack (%d): ", nStack );
-for ( int i = 0; i < nStack; ++i )
+for ( sal_uInt32 i = 0; i < nStack; ++i )
fprintf( stderr, "0x%lx, ", pStack[i] );
fprintf( stderr, "\n" );
}
@@ -294,6 +294,10 @@ static void cpp_call(
sal_Int32 nParams, typelib_MethodParameter * pParams,
void * pUnoReturn, void * pUnoArgs[], uno_Any ** ppUnoExc )
{
+#if OSL_DEBUG_LEVEL > 2
+fprintf( stderr, "= cpp_call() =\n" );
+#endif
+
// max space for: [complex ret ptr], values|ptr ...
sal_uInt64 * pStack = (sal_uInt64 *)alloca( (nParams+3) *
sizeof(sal_Int64) );
sal_uInt64 * pStackStart = pStack;
@@ -333,7 +337,7 @@ static void cpp_call(
pCppReturn = (bridges::cpp_uno::shared::relatesToInterfaceType(
pReturnTypeDescr )
? alloca( pReturnTypeDescr->nSize ) : pUnoReturn);
#if OSL_DEBUG_LEVEL > 2
-fprintf(stderr, "pCppReturn/pUnoReturn is %lx/%lx", pCppReturn,
pUnoReturn);
+fprintf(stderr, "pCppReturn/pUnoReturn is %p/%p\n", pCppReturn,
pUnoReturn);
#endif
INSERT_INT64( , nGPR, pGPR, pStack, bOverflow );
}
@@ -378,7 +382,7 @@ static void cpp_call(
case typelib_TypeClass_HYPER:
case typelib_TypeClass_UNSIGNED_HYPER:
#if OSL_DEBUG_LEVEL > 2
-fprintf(stderr, "hyper is %lx\n",
pCppArgs[nPos]);
+fprintf(stderr, "hyper is 0x%lx\n",
*(sal_Int64 *)pCppArgs[nPos]);
#endif
INSERT_INT64( pCppArgs[nPos], nGPR, pGPR,
pStack, bOverflow );
break;
@@ -386,7 +390,7 @@ static void cpp_call(
case typelib_TypeClass_UNSIGNED_LONG:
case typelib_TypeClass_ENUM:
#if OSL_DEBUG_LEVEL > 2
-fprintf(stderr, "long is %x\n",
pCppArgs[nPos]);
+fprintf(stderr, "long is 0x%x\n", *(sal_Int32
*)pCppArgs[nPos]);
#endif
INSERT_INT32( pCppArgs[nPos], nGPR, pGPR,
pStack, bOverflow );
break;
@@ -448,7 +452,7 @@ static void cpp_call(
else // direct way
{
#if OSL_DEBUG_LEVEL > 2
-fprintf(stderr, "that one, passing %lx through\n",
pUnoArgs[nPos]);
+fprintf(stderr, "that one, passing %p through\n",
pUnoArgs[nPos]);
#endif
pCppArgs[nPos] = pUnoArgs[nPos];
// no longer needed
Re: UNO bridge not fully ABI compliant on ppc64le
On Tue, 5 Sep 2023 15:01:03 +0200 Dan Horák wrote: > Hello, > > after quite some debugging the failure in DEC2BIN() function in the > CppunitTest_sc_addin_functions_test on ppc64le we have confirmed that > the UNO bridge isn't fully ABI compliant. For example int32 parameters > are not correctly sign-extended to 64-bit values. Please see > https://bugzilla.redhat.com/show_bug.cgi?id=2237384 for all the details. and it should be fixed with https://gerrit.libreoffice.org/c/core/+/156846 https://gerrit.libreoffice.org/c/core/+/156847 Dan
Re: CppunitTest_dbaccess_hsqldb_test failure
On Fri, 8 Sep 2023 16:17:19 +0200 Dan Horák wrote: > On Fri, 8 Sep 2023 14:02:54 +0200 > Dan Horák wrote: > > > Hello, > > > > I am seeing CppunitTest_dbaccess_hsqldb_test failing on some systems and > > on some occasions. > > > > ... > > Running scope as unit: > > -home-jenkins-workspace-libreoffice\x2dupstream\x2dbundled-label-LO\x2dppc64le-workdir-CppunitTest-dbaccess_hsqldb_test.test:20230907213220:2142227.scope > > [_RUN_] HSQLDBTest::testEmptyDBConnection > > HSQLDBTest::testEmptyDBConnection finished in: 1353ms > > OK (1) > >PID: 2142247 (cppunittester) > >UID: 1003 (jenkins) > >GID: 1003 (jenkins) > > Signal: 5 (TRAP) > > Timestamp: Thu 2023-09-07 21:32:22 UTC (15s ago) > > Command Line: > > /home/jenkins/workspace/libreoffice-upstream-bundled/label/LO-ppc64le/workdir/LinkTarget/Executable/cppunittester > > > > /home/jenkins/workspace/libreoffice-upstream-bundled/label/LO-ppc64le/workdir/LinkTarget/CppunitTest/libtest_dbaccess_hsqldb_test.so > > --headless > > -env:BRAND_BASE_DIR=file:///home/jenkins/workspace/libreoffice-upstream-bundled/label/LO-ppc64le/instdir > > -env:BRAND_SHARE_SUBDIR=share > > -env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource > > ... > > > > > > I suspect it's because the time to complete the check is over 1000ms. > > When the run time captured in > > workdir/CppunitTest/dbaccess_hsqldb_test.test.log > > is bellow 1000 (usually 600-800ms), the test passes. The obvious > > question is where I can extend the timeout? > > hmm, or it is not a timeout, got a passed test with added 5 sec sleep > in HSQLDBTest::testEmptyDBConnection() ... and I am having the same experience with CppunitTest_dbaccess_RowSetClones, seems good, but then a SIGTRAP from inside Java ... [_RUN_] RowSetClones::test RowSetClones::test finished in: 1983ms OK (1) PID: 105663 (cppunittester) UID: 1001 (sharkcz) GID: 1001 (sharkcz) Signal: 5 (TRAP) Timestamp: Mon 2023-09-11 11:55:03 UTC (9s ago) ... Maybe there is also an ABI UNO issue in Java (similar to what has been discovered by the bridgetest failure) ... Dan
Re: CppunitTest_dbaccess_hsqldb_test failure
On Fri, 8 Sep 2023 14:02:54 +0200 Dan Horák wrote: > Hello, > > I am seeing CppunitTest_dbaccess_hsqldb_test failing on some systems and > on some occasions. > > ... > Running scope as unit: > -home-jenkins-workspace-libreoffice\x2dupstream\x2dbundled-label-LO\x2dppc64le-workdir-CppunitTest-dbaccess_hsqldb_test.test:20230907213220:2142227.scope > [_RUN_] HSQLDBTest::testEmptyDBConnection > HSQLDBTest::testEmptyDBConnection finished in: 1353ms > OK (1) >PID: 2142247 (cppunittester) >UID: 1003 (jenkins) >GID: 1003 (jenkins) > Signal: 5 (TRAP) > Timestamp: Thu 2023-09-07 21:32:22 UTC (15s ago) > Command Line: > /home/jenkins/workspace/libreoffice-upstream-bundled/label/LO-ppc64le/workdir/LinkTarget/Executable/cppunittester > > /home/jenkins/workspace/libreoffice-upstream-bundled/label/LO-ppc64le/workdir/LinkTarget/CppunitTest/libtest_dbaccess_hsqldb_test.so > --headless > -env:BRAND_BASE_DIR=file:///home/jenkins/workspace/libreoffice-upstream-bundled/label/LO-ppc64le/instdir > -env:BRAND_SHARE_SUBDIR=share > -env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource > ... > > > I suspect it's because the time to complete the check is over 1000ms. > When the run time captured in > workdir/CppunitTest/dbaccess_hsqldb_test.test.log > is bellow 1000 (usually 600-800ms), the test passes. The obvious > question is where I can extend the timeout? hmm, or it is not a timeout, got a passed test with added 5 sec sleep in HSQLDBTest::testEmptyDBConnection() ... Dan
CppunitTest_dbaccess_hsqldb_test failure
Hello, I am seeing CppunitTest_dbaccess_hsqldb_test failing on some systems and on some occasions. ... Running scope as unit: -home-jenkins-workspace-libreoffice\x2dupstream\x2dbundled-label-LO\x2dppc64le-workdir-CppunitTest-dbaccess_hsqldb_test.test:20230907213220:2142227.scope [_RUN_] HSQLDBTest::testEmptyDBConnection HSQLDBTest::testEmptyDBConnection finished in: 1353ms OK (1) PID: 2142247 (cppunittester) UID: 1003 (jenkins) GID: 1003 (jenkins) Signal: 5 (TRAP) Timestamp: Thu 2023-09-07 21:32:22 UTC (15s ago) Command Line: /home/jenkins/workspace/libreoffice-upstream-bundled/label/LO-ppc64le/workdir/LinkTarget/Executable/cppunittester /home/jenkins/workspace/libreoffice-upstream-bundled/label/LO-ppc64le/workdir/LinkTarget/CppunitTest/libtest_dbaccess_hsqldb_test.so --headless -env:BRAND_BASE_DIR=file:///home/jenkins/workspace/libreoffice-upstream-bundled/label/LO-ppc64le/instdir -env:BRAND_SHARE_SUBDIR=share -env:BRAND_SHARE_RESOURCE_SUBDIR=program/resource ... I suspect it's because the time to complete the check is over 1000ms. When the run time captured in workdir/CppunitTest/dbaccess_hsqldb_test.test.log is bellow 1000 (usually 600-800ms), the test passes. The obvious question is where I can extend the timeout? Thanks, Dan
MAKEFLAGS ignored?
Hello, I was trying to pass the "--keep-going" option to the Makefile via the MAKEFLAGS [1] to get as much test failures as possible in a single run, but it seems to be ignored. After reading the make manual for the value function [2], I think GMAKE_OPTIONS definition should rather look like -export GMAKE_OPTIONS?=-r$(if $(verbose),,s)$(value $(MAKEFLAGS)) +export GMAKE_OPTIONS?=-r$(if $(verbose),,s) $(value MAKEFLAGS) What do you think? [1] https://git.libreoffice.org/core/+/refs/heads/master/Makefile.in#78 [2] https://www.gnu.org/software/make/manual/html_node/Value-Function.html Thanks, Dan
Re: recent KahanSum change causes a new test failure on ppc64le
On Wed, 6 Sep 2023 16:32:49 +0200 Xisco Fauli wrote: > Hello Dan, > > That test is indeed testing the patch you are reverting, so it's > expected to fail. It shouldn't fail if you also revert > 2ac7d339a97efa638124c2862551e0876487833b. thanks, it makes sense (and helps) :-) Dan > On 6/9/23 15:41, Dan Horák wrote: > > On Tue, 5 Sep 2023 18:53:37 +0200 > > Dan Horák wrote: > > > >> Hello, > >> > >> seems the recent change [1] to KahanSum handling causes a test failure > >> on ppc64le. > >> > >> [1] > >> https://git.libreoffice.org/core/+/1f8cc7644293e62ad6430bbeec243d3283e478d7 > >> > > and with the change reverted I am getting a failure in > > CppunitTest_sc_ucalc_formula2 > > > > ... > > testTdf147398::TestBody finished in: 11ms > > [_RUN_] testTdf156985::TestBody > > /home/sharkcz/projects/libreoffice/sc/qa/unit/ucalc_formula2.cxx: > > 4624:testTdf156985::TestBody equality assertion failed > > - Expected: 0 > > - Actual : -1.59872115546023e-14 > > > > testTdf156985::TestBody finished in: 11ms > > ... > > > > so not good ... > > > > > > Dan > > -- > Xisco Faulí > LibreOffice QA Team > IRC: x1sc0 >
Re: recent KahanSum change causes a new test failure on ppc64le
On Thu, 7 Sep 2023 08:16:28 +0200 Stephan Bergmann wrote: > On 9/5/23 18:53, Dan Horák wrote: > > seems the recent change [1] to KahanSum handling causes a test failure > > on ppc64le. > > > > Running scope as unit: > > -home-sharkcz-projects-libreoffice-workdir-CppunitTest-sc_statistical_functions_test.test:20230905152639:2378561.scope > > [_RUN_] StatisticalFunctionsTest::testStatisticalFormulasFODS > > Testing load > > file:///home/sharkcz/projects/libreoffice//sc/qa/unit/data/functions/statistical/fods/KahanSum.fods: > > /home/sharkcz/projects/libreoffice/sc/qa/unit/functions_test.cxx:49:StatisticalFunctionsTest::testStatisticalFormulasFODS > > forced failure > > - Testing > > file:///home/sharkcz/projects/libreoffice//sc/qa/unit/data/functions/statistical/fods/KahanSum.fods > > failed, Sheet2.A90 '=SUM(F3:F102)' result: 6.6, expected: 5 > > Interesting; I also saw that failure with my latest local build on macOS > aarch64 against Clang trunk. (But didn't debug it further and wrote it > off as maybe some intermittent Clang trunk bug.) > someone on IRC reported the same issue, also from macOS I believe Dan
Re: recent KahanSum change causes a new test failure on ppc64le
On Tue, 5 Sep 2023 18:53:37 +0200 Dan Horák wrote: > Hello, > > seems the recent change [1] to KahanSum handling causes a test failure > on ppc64le. > > [1] > https://git.libreoffice.org/core/+/1f8cc7644293e62ad6430bbeec243d3283e478d7 and with the change reverted I am getting a failure in CppunitTest_sc_ucalc_formula2 ... testTdf147398::TestBody finished in: 11ms [_RUN_] testTdf156985::TestBody /home/sharkcz/projects/libreoffice/sc/qa/unit/ucalc_formula2.cxx: 4624:testTdf156985::TestBody equality assertion failed - Expected: 0 - Actual : -1.59872115546023e-14 testTdf156985::TestBody finished in: 11ms ... so not good ... Dan
Re: new bridgetest failures in 7.6 on ppc64le/s390x
On Mon, 4 Sep 2023 17:56:19 +0200 Rene Engelhard wrote: > Hi, > > Am 04.09.23 um 14:23 schrieb Dan Horák: > > for the record, we haven't seen this issue on s390x in Fedora, only on > > ppc64le. > > Interesting. (Note that I don't run "all the other tests" on > !amd64/!arm64/!armhf because of the sysiphos work dealt with in the > other thread, but just testtools and the sal, cppuhelper etc. tests) and I was wrong, seems we had disabled the bridge tests long time ago on s390x in the distro builds, but when I tried a manual build I got the same issues reported as you. So the Java UNO bridge is also broken on s390x (for a long time) ... Dan
recent KahanSum change causes a new test failure on ppc64le
Hello, seems the recent change [1] to KahanSum handling causes a test failure on ppc64le. Running scope as unit: -home-sharkcz-projects-libreoffice-workdir-CppunitTest-sc_statistical_functions_test.test:20230905152639:2378561.scope [_RUN_] StatisticalFunctionsTest::testStatisticalFormulasFODS Testing load file:///home/sharkcz/projects/libreoffice//sc/qa/unit/data/functions/statistical/fods/KahanSum.fods: /home/sharkcz/projects/libreoffice/sc/qa/unit/functions_test.cxx:49:StatisticalFunctionsTest::testStatisticalFormulasFODS forced failure - Testing file:///home/sharkcz/projects/libreoffice//sc/qa/unit/data/functions/statistical/fods/KahanSum.fods failed, Sheet2.A90 '=SUM(F3:F102)' result: 6.6, expected: 5 StatisticalFunctionsTest::testStatisticalFormulasFODS finished in: 389ms functions_test.cxx:49:Assertion Test name: StatisticalFunctionsTest::testStatisticalFormulasFODS forced failure - Testing file:///home/sharkcz/projects/libreoffice//sc/qa/unit/data/functions/statistical/fods/KahanSum.fods failed, Sheet2.A90 '=SUM(F3:F102)' result: 6.6, expected: 5 Failures !!! Run: 1 Failure total: 1 Failures: 1 Errors: 0 [1] https://git.libreoffice.org/core/+/1f8cc7644293e62ad6430bbeec243d3283e478d7 Thanks, Dan
UNO bridge not fully ABI compliant on ppc64le
Hello, after quite some debugging the failure in DEC2BIN() function in the CppunitTest_sc_addin_functions_test on ppc64le we have confirmed that the UNO bridge isn't fully ABI compliant. For example int32 parameters are not correctly sign-extended to 64-bit values. Please see https://bugzilla.redhat.com/show_bug.cgi?id=2237384 for all the details. With regards, Dan
[Libreoffice-commits] core.git: sc/qa
sc/qa/unit/functions_array.cxx |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
New commits:
commit 3426c96d0e32e0c83e4ce5fdb3405787a0c81e6c
Author: Dan Horák
AuthorDate: Fri Sep 1 18:45:42 2023 +0200
Commit: Stephan Bergmann
CommitDate: Mon Sep 4 14:46:34 2023 +0200
limit tests giving dubious results to x86_64
We have confirmed that ArrayFunctionsTest::testDubiousArrayFormulasFODS
gives different results depending on the -ffp-contract setting on
ppc64le and likely also on s390x in addition to aarch64. Thus limit the
check only to x86_64 where it's known to give consistent results.
Change-Id: Iedb63fb4340cfe9a88e374c7498d97574bcdfcc7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156453
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann
diff --git a/sc/qa/unit/functions_array.cxx b/sc/qa/unit/functions_array.cxx
index 7584c4e0b309..2053c44dfad7 100644
--- a/sc/qa/unit/functions_array.cxx
+++ b/sc/qa/unit/functions_array.cxx
@@ -27,8 +27,9 @@ void ArrayFunctionsTest::testDubiousArrayFormulasFODS()
{
//TODO: sc/qa/unit/data/functions/array/dubious/fods/linest.fods produces
widely different
// values when built with -ffp-contract enabled (-ffp-contract=on default
on Clang 14,
-// -ffp-contract=fast default when building with optimizations on GCC) on
at least aarch64:
-#if !((defined __clang__ || defined __GNUC__) && defined __aarch64__)
+// -ffp-contract=fast default when building with optimizations on GCC) on
at least aarch64
+// and ppc64le. Thus limit the check only to platforms with consistent
results.
+#if defined X86_64
OUString aDirectoryURL
=
m_directories.getURLFromSrc(u"/sc/qa/unit/data/functions/array/dubious/fods/");
recursiveScan(test::pass, "OpenDocument Spreadsheet Flat XML",
aDirectoryURL,
Re: new bridgetest failures in 7.6 on ppc64le/s390x (was: Re: new bridgetest failures in 7.6 on ppc64le)
On Sat, 2 Sep 2023 19:13:44 +0200 Rene Engelhard wrote: > Hi, > > Am 02.09.23 um 09:33 schrieb Rene Engelhard: > > Hi, > > > > Am 31.08.23 um 10:21 schrieb Dan Horák: > >> ... > >> [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. > > > > Ah, thanks. I tried with the actual bridge commits but didn't try this > > one. > > > > Indeed reverting it fixes it. > > > > > > BTw, s390x seems to have a similar problem, see > > https://buildd.debian.org/status/fetch.php?pkg=libreoffice=s390x=4%3A7.6.1%7Erc1-1=1692862844=1. > > > > Trying whether reverting that patch also fixes it. > > > yup, it does make the test pass again. "fix" is wrong here somehow ;-) for the record, we haven't seen this issue on s390x in Fedora, only on ppc64le. The revert only works around the actual problem, because the Java bridge tests aren't run any more for "make unitcheck", but the real issue is still there. Dan
Re: ArrayFunctionsTest::testDubiousArrayFormulasFODS fails on ppc64le (and s390x)
On Fri, 1 Sep 2023 16:36:30 +0200 Stephan Bergmann wrote: > On 9/1/23 15:41, Dan Horák wrote: > > On Fri, 1 Sep 2023 11:29:23 +0200 > > Stephan Bergmann wrote: > [...] > >> would be that the TODO comment makes it then sound like the issues on > >> ppc64le and s390x are also known to be due to -ffp-contract settings, > >> even if you would not verify that. > > > > I have verified it's indeed caused by -ffp-contract. When set to "off", > > the test passes (checked on ppc64le). > > Good to know. Please add that knowledge to the commit message. > > >> So maybe the best thing is to turn this into a x86_64 only conditional, > >> and extend the TODO comment with something like "...on at least aarch64, > >> so lets only execute this on x86-64, where it appears to always work well:" > > > > yeah, I think using a "positive" list would be better. I could > > possibly prepare a patch, but is there an example where I can see how > > the condition should look like? > > For better or worse, we pass or configure.ac's "compiler independent" > CPUNAME into the compiler via -D$(CPUNAME) (solenv/gbuild/gbuild.mk), so > something like > > > #if defined X86_64 > > should work for a positive list of just x86_64, regardless of compiler > (MSVC vs. Clang/GCC). > thanks, fix posted for review in https://gerrit.libreoffice.org/c/core/+/156453 Dan
Dan Horák license statement
All of my past & future contributions to LibreOffice may be licensed under the MPLv2/LGPLv3+ dual license.
Re: ArrayFunctionsTest::testDubiousArrayFormulasFODS fails on ppc64le (and s390x)
On Fri, 1 Sep 2023 11:29:23 +0200
Stephan Bergmann wrote:
> On 9/1/23 10:37, Dan Horák wrote:
> > The "dubious array" tests are already being skipped for aarch64 due
> > known issue [1], shouldn't we just skip them for ppc64le and s390x as
> > well? Or should it be enabled only for "good" platforms, eg. x86_64?
>
> I think either approach should be OK, whatever you find more convenient.
> One minor downside when adding additional conditionals to skip on
> ppc64le and s390x to
>
> > void ArrayFunctionsTest::testDubiousArrayFormulasFODS()
> > {
> > //TODO: sc/qa/unit/data/functions/array/dubious/fods/linest.fods
> > produces widely different
> > // values when built with -ffp-contract enabled (-ffp-contract=on
> > default on Clang 14,
> > // -ffp-contract=fast default when building with optimizations on GCC)
> > on at least aarch64:
> > #if !((defined __clang__ || defined __GNUC__) && defined __aarch64__)
> > OUString aDirectoryURL
> > =
> > m_directories.getURLFromSrc(u"/sc/qa/unit/data/functions/array/dubious/fods/");
> > recursiveScan(test::pass, "OpenDocument Spreadsheet Flat XML",
> > aDirectoryURL,
> >
> > "com.sun.star.comp.filter.OdfFlatXml,,com.sun.star.comp.Calc.XMLOasisImporter,com.sun.star.comp.Calc.XMLOasisExporter,,,true",
> > FODS_FORMAT_TYPE, SotClipboardFormatId::NONE, 0, false);
> > #endif
> > }
>
> would be that the TODO comment makes it then sound like the issues on
> ppc64le and s390x are also known to be due to -ffp-contract settings,
> even if you would not verify that.
I have verified it's indeed caused by -ffp-contract. When set to "off",
the test passes (checked on ppc64le). But what's more interesting, that
the "off" setting also fixes a failure in
AddinFunctionsTest::testAddinFormulasFODS when dec2bin() is converting
negative numbers. dec2bin(-100) and dec2bin(-2) report Error:502
instead of doing the conversion ...
> So maybe the best thing is to turn this into a x86_64 only conditional,
> and extend the TODO comment with something like "...on at least aarch64,
> so lets only execute this on x86-64, where it appears to always work well:"
yeah, I think using a "positive" list would be better. I could
possibly prepare a patch, but is there an example where I can see how
the condition should look like?
> (The underlying issue is that tests like this are, excuse my wording,
> utter crap. Instead of checking for exact values, they should of course
> check that results are in whatever acceptable range according to a spec.
> But Calc doesn't even come with such a spec in the first place...)
we have seen more problems in other packages in the past related to
-ffp-contract behaviour on aarch64 and s390x and ppc64le ...
Dan
ArrayFunctionsTest::testDubiousArrayFormulasFODS fails on ppc64le (and s390x)
Hello, the ArrayFunctionsTest::testDubiousArrayFormulasFODS test fails on ppc64le (and s390x) with a precision issue, see bellow [_RUN_] ArrayFunctionsTest::testDubiousArrayFormulasFODS Testing load file:///home/sharkcz/projects/libreoffice//sc/qa/unit/data/functions/array/dubious/fods/linest.fods: /home/sharkcz/projects/libreoffice/sc/qa/unit/functions_test.cxx:49:ArrayFunctionsTest::testDubiousArrayFormulasFODS forced failure - Testing file:///home/sharkcz/projects/libreoffice//sc/qa/unit/data/functions/array/dubious/fods/linest.fods failed, Sheet2.A39 '=O30' result: 12237.3616028623, expected: 12237.3616028624 Opening the linest.fods file shows more failed tests ... The "dubious array" tests are already being skipped for aarch64 due known issue [1], shouldn't we just skip them for ppc64le and s390x as well? Or should it be enabled only for "good" platforms, eg. x86_64? [1] https://git.libreoffice.org/core/+/refs/heads/master/sc/qa/unit/functions_array.cxx#31 Dan
Re: new bridgetest failures in 7.6 on ppc64le
On Thu, 31 Aug 2023 10:21:05 +0200 Dan Horák 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? Dan
new bridgetest failures in 7.6 on ppc64le
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. The plan is to looks at the other new failures as well, set a baseline and then run some CI to catch any new issues early. Thanks, Dan
