Processed: Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 935902 g++-9
Bug #935902 [libcppunit-dev] libcppunit-dev: segfault when using with a program 
compiled with g++-9
Bug reassigned from package 'libcppunit-dev' to 'g++-9'.
No longer marked as found in versions cppunit/1.14.0-4.
Ignoring request to alter fixed versions of bug #935902 to the same values 
previously set
> affects 935902 libcppunit-dev
Bug #935902 [g++-9] libcppunit-dev: segfault when using with a program compiled 
with g++-9
Added indication that 935902 affects libcppunit-dev
> found 935902 9.2.1-12
Bug #935902 [g++-9] libcppunit-dev: segfault when using with a program compiled 
with g++-9
Marked as found in versions gcc-9/9.2.1-12.
> close 935902 9.2.1-16
Bug #935902 [g++-9] libcppunit-dev: segfault when using with a program compiled 
with g++-9
Marked as fixed in versions gcc-9/9.2.1-16.
Bug #935902 [g++-9] libcppunit-dev: segfault when using with a program compiled 
with g++-9
Marked Bug as done
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
935902: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935902
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

[Rene Engelhard]

reassign 935902 g++-9
affects 935902 libcppunit-dev
found 935902 9.2.1-12
close 935902 9.2.1-16
thanks

Hi,

On Thu, Oct 31, 2019 at 03:15:10PM +0100, Matthias Klose wrote:
> The comment about cppunit made me look at the cppunit package to find
> #935902, and yes, the test case is reproducible. So looking at the test

Ah, that one...

Reassigning to gcc (and marking as fixed)

> failure would have been revealed that the test frame work is broken, not a
> single test. This turned out to be https://gcc.gnu.org/PR92267, causing an
> ABI breakage in cppunit.

OK.

> The fix is now in -16.

Good. Can confirm. You can close the bug.

Regards,

Rene

Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

[Matthias Klose]

>> And afaik there was no test rebuild for bullseye
>> either.
>
> It does not help to blame people for not doing a rebuild when there is no 
rebuild necessary.


Please could you turn off your mode feeling attacked by any email, before you 
understood these?


On 31.10.19 15:33, rene.engelh...@mailbox.org wrote:

Hi,

Am 31. Oktober 2019 15:15:10 MEZ schrieb Matthias Klose :

And afaik there was no test rebuild for
bullseye
either.


Accepted cppunit 1.14.0-4 (source) into unstable
On July 26:
https://tracker.debian.org/news/1049803/accepted-cppunit-1140-4-source-into-unstable/

Buster release was 3 weeks before that. So this "no test rebuild for bullseye" 
is not true.


bullseye didn't see any test rebuild of the archive, and filing of FTBFS bugs 
yet.

Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

[rene . engelhard]

Hi,

Am 31. Oktober 2019 15:15:10 MEZ schrieb Matthias Klose :
>And afaik there was no test rebuild for
>bullseye 
>either.

Accepted cppunit 1.14.0-4 (source) into unstable 
On July 26: 
https://tracker.debian.org/news/1049803/accepted-cppunit-1140-4-source-into-unstable/

Buster release was 3 weeks before that. So this "no test rebuild for bullseye" 
is not true.

Regards

Rene

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

[rene . engelhard]

Hi,

Am 31. Oktober 2019 15:15:10 MEZ schrieb Matthias Klose :
>On 29.10.19 15:09, Vincent Lefevre wrote:
>> On 2019-10-29 13:09:46 +0100, rene.engelh...@mailbox.org wrote:
>>> Am 29. Oktober 2019 12:49:44 MEZ schrieb Vincent Lefevre
>:
 In case makefile magic triggers some rebuild, you can also run the
 generated executable directly (with the right environment
>variables,
 in case this matters). If the programs honors the system ABI, this
 is allowed, and you'll effectively test the new libstdc++6.
>>>
>>> No, if the rebuild rebuilds cppunittester or one of the
>>> exceptionprotectors or the smoketest so or similar we are at the
>>> same situation as with the autopkgtest (that's what it builds) and
>>> are not sure whether it's g++-9 or libstdc++6. Neither LO nor the
>>> test are an executable it's a executable with gazillions of .sos.
>> 
>> I meant running the generated program (smoketest) without rebuilding
>> it:
>> 
>> 1. Build smoketest with the old g++-9 / libstdc++6.
>> 2. Upgrade g++-9 / libstdc++6.
>> 3. Run smoketest directly.
>> 
>> (I assume that the smoketest executable does not invoke g++-9 to
>> rebuild things on the fly.)
>
>I'm not sure if Rene wants to help tracking this down, he just disabled
>running 
>the test in
>https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/99764f8d0df2f40aba9a220a8a4858d3f6d05494

*temporarily*

>and introducing a typo in
>https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/998c3b1c63bbedf8d886227749279d7ccb26a30b
>So maybe don't commit if you are angry.
>

Maybe, yes, but I needed to get it builds le got the upload. Will fix, thanks.

><_rene_> how supported is clang on the various (release) archs?
><_rene_> completely?
><_rene_> (clang++ if it matters)
><_rene_> (actually probably only matters for amd64/arm64 for now,
>but...)
>
>so I assume we cannot expect Rene's help for that issue anymore.

Unfortunately the tests fail when LO is built with clang. So yes, we need to 
track it down.

>The comment about cppunit made me look at the cppunit package to find
>#935902, 
>and yes, the test case is reproducible. So looking at the test failure
>would 
>have been revealed that the test frame work is broken, not a single
>test. 

I said in some comment that "the first" test failed: basic_scanner.

I didn't say smoketest was the only one. It's the only one done in autopkgtest 
though.

This 
>turned out to be https://gcc.gnu.org/PR92267, causing an ABI breakage
>in 
>cppunit. The fix is now in -16.

Ok. Will try. Then I can add build-conflcts or so and reenable the tests.

>So a symbols file and a test rebuild should have at least flagged
>something, however cppunit doesn't have symbols files, because the
>package 
>maintainer doesn't like them.

For C++ and the mangling and handling it in all arxgs, yes.

> And afaik there was no test rebuild for
bullseye 
>l either.

It does not help to blame people for not doing a rebuild when there is no 
rebuild necessary.

Regards

Rene

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

[Matthias Klose]

On 29.10.19 15:09, Vincent Lefevre wrote:

On 2019-10-29 13:09:46 +0100, rene.engelh...@mailbox.org wrote:

Am 29. Oktober 2019 12:49:44 MEZ schrieb Vincent Lefevre :

In case makefile magic triggers some rebuild, you can also run the
generated executable directly (with the right environment variables,
in case this matters). If the programs honors the system ABI, this
is allowed, and you'll effectively test the new libstdc++6.


No, if the rebuild rebuilds cppunittester or one of the
exceptionprotectors or the smoketest so or similar we are at the
same situation as with the autopkgtest (that's what it builds) and
are not sure whether it's g++-9 or libstdc++6. Neither LO nor the
test are an executable it's a executable with gazillions of .sos.


I meant running the generated program (smoketest) without rebuilding
it:

1. Build smoketest with the old g++-9 / libstdc++6.
2. Upgrade g++-9 / libstdc++6.
3. Run smoketest directly.

(I assume that the smoketest executable does not invoke g++-9 to
rebuild things on the fly.)


I'm not sure if Rene wants to help tracking this down, he just disabled running 
the test in

https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/99764f8d0df2f40aba9a220a8a4858d3f6d05494
and introducing a typo in
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/998c3b1c63bbedf8d886227749279d7ccb26a30b
So maybe don't commit if you are angry.

<_rene_> how supported is clang on the various (release) archs?
<_rene_> completely?
<_rene_> (clang++ if it matters)
<_rene_> (actually probably only matters for amd64/arm64 for now, but...)

so I assume we cannot expect Rene's help for that issue anymore.


The comment about cppunit made me look at the cppunit package to find #935902, 
and yes, the test case is reproducible. So looking at the test failure would 
have been revealed that the test frame work is broken, not a single test. This 
turned out to be https://gcc.gnu.org/PR92267, causing an ABI breakage in 
cppunit. The fix is now in -16.


So a symbols file and a test rebuild should have at least flagged
something, however cppunit doesn't have symbols files, because the package 
maintainer doesn't like them.  And afaik there was no test rebuild for bullseye 
either.


The upstream issue was introduced in May, I don't know why it's only seen now.

Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

[rene . engelhard]

Hi,

Am 29. Oktober 2019 15:09:50 MEZ schrieb Vincent Lefevre :
>On 2019-10-29 13:09:46 +0100, rene.engelh...@mailbox.org wrote:
>> Am 29. Oktober 2019 12:49:44 MEZ schrieb Vincent Lefevre
>:
>> >In case makefile magic triggers some rebuild, you can also run the
>> >generated executable directly (with the right environment variables,
>> >in case this matters). If the programs honors the system ABI, this
>> >is allowed, and you'll effectively test the new libstdc++6.
>> 
>> No, if the rebuild rebuilds cppunittester or one of the
>> exceptionprotectors or the smoketest so or similar we are at the
>> same situation as with the autopkgtest (that's what it builds) and
>> are not sure whether it's g++-9 or libstdc++6. Neither LO nor the
>> test are an executable it's a executable with gazillions of .sos.
>
>I meant running the generated program (smoketest) without rebuilding
>it:

Smoketest is not a program but also a libsmoketest.so "ran" by cppunittester.

>1. Build smoketest with the old g++-9 / libstdc++6.
>2. Upgrade g++-9 / libstdc++6.
>3. Run smoketest directly.

That would need to copy the longish command from the old log, but yeah.

>(I assume that the smoketest executable does not invoke g++-9 to
>rebuild things on the fly.)

No, but make check in smokest might rebuild stuff. That was what I was aiming 
at. This already happens in "normal" builds.

Regards

Rene

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

[Vincent Lefevre]

On 2019-10-29 13:09:46 +0100, rene.engelh...@mailbox.org wrote:
> Am 29. Oktober 2019 12:49:44 MEZ schrieb Vincent Lefevre :
> >In case makefile magic triggers some rebuild, you can also run the
> >generated executable directly (with the right environment variables,
> >in case this matters). If the programs honors the system ABI, this
> >is allowed, and you'll effectively test the new libstdc++6.
> 
> No, if the rebuild rebuilds cppunittester or one of the
> exceptionprotectors or the smoketest so or similar we are at the
> same situation as with the autopkgtest (that's what it builds) and
> are not sure whether it's g++-9 or libstdc++6. Neither LO nor the
> test are an executable it's a executable with gazillions of .sos.

I meant running the generated program (smoketest) without rebuilding
it:

1. Build smoketest with the old g++-9 / libstdc++6.
2. Upgrade g++-9 / libstdc++6.
3. Run smoketest directly.

(I assume that the smoketest executable does not invoke g++-9 to
rebuild things on the fly.)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

[rene . engelhard]

Hi,

Am 29. Oktober 2019 12:49:44 MEZ schrieb Vincent Lefevre :
>In case makefile magic triggers some rebuild, you can also run the
>generated executable directly (with the right environment variables,
>in case this matters). If the programs honors the system ABI, this
>is allowed, and you'll effectively test the new libstdc++6.

No, if the rebuild rebuilds cppunittester or one of the exceptionprotectors or 
the smoketest so or similar we are at the same situation as with the 
autopkgtest (that's what it builds) and are not sure whether it's g++-9 or 
libstdc++6. Neither LO nor the test are an executable it's a executable with 
gazillions of .sos.

Regards

Rene

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

[Vincent Lefevre]

On 2019-10-29 11:52:55 +0100, rene.engelh...@mailbox.org wrote:
> Hi again,
> 
> Am 29. Oktober 2019 11:26:41 MEZ schrieb rene.engelh...@mailbox.org:
> >Hi,
> >
> >Am 29. Oktober 2019 10:59:07 MEZ schrieb Vincent Lefevre
> >:
> >> If you build LO
> >>with an older gcc-9 version, upgrade libstdc++6, and run the test
> >>again (without rebuilding it), does it fail?
> >
> >This is impossible. This is a C++ unit test and the stuff assumes too
> >much of the build tree. You need to actually build the test libs etc to
> >run it. 
> >
> >That is why autopkgtest does only smoketest [...]
> 
> Well, thinking about it it might be possible. Build on testing,
> debian/tests/smoketest, dist-upgrade to did and rerun it and hope
> some makefile magic doesn't trigger some rebuild...

In case makefile magic triggers some rebuild, you can also run the
generated executable directly (with the right environment variables,
in case this matters). If the programs honors the system ABI, this
is allowed, and you'll effectively test the new libstdc++6.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

[rene . engelhard]

Hi again,

Am 29. Oktober 2019 11:26:41 MEZ schrieb rene.engelh...@mailbox.org:
>Hi,
>
>Am 29. Oktober 2019 10:59:07 MEZ schrieb Vincent Lefevre
>:
>> If you build LO
>>with an older gcc-9 version, upgrade libstdc++6, and run the test
>>again (without rebuilding it), does it fail?
>
>This is impossible. This is a C++ unit test and the stuff assumes too
>much of the build tree. You need to actually build the test libs etc to
>run it. 
>
>That is why autopkgtest does only smoketest [...]

Well, thinking about it it might be possible. Build on testing, 
debian/tests/smoketest, dist-upgrade to did and rerun it and hope some makefile 
magic doesn't trigger some rebuild...

The smokest (except the cppunit blurb)  just does "run lo, open 
smoketestdoc.sxw, run some macros to test basic stuff".

Will try...

Regards

Rene

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

[rene . engelhard]

Hi,

Am 29. Oktober 2019 10:59:07 MEZ schrieb Vincent Lefevre :
> If you build LO
>with an older gcc-9 version, upgrade libstdc++6, and run the test
>again (without rebuilding it), does it fail?

This is impossible. This is a C++ unit test and the stuff assumes too much of 
the build tree. You need to actually build the test libs etc to run it. 

That is why autopkgtest does only smoketest instead of all c++ unit tests even 
though the latter would be helpful.
Tried to decouple it once but failed as it always either wanted something 
present it write in the "instdir".

Regards

Rene

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)

[Vincent Lefevre]

On 2019-10-28 23:34:11 +0100, Rene Engelhard wrote:
> You like to make other people bad where this is not the case. In this
> case this is not a LO bug since the exact same LO version worked until
> said gcc upload.

If the LO code has some undefined behavior, it could also be a LO bug
triggered by some new optimization or other change in the compiler.

That said, when seeing a new failure with a new GCC version for MPFR,
in (almost) all cases, this was due to a bug in GCC (after I spent
some time to build a simple testcase). But note that I also test MPFR
with sanitizer options, so that if there is some UB in MPFR, I would
probably notice it first.

I notice that this bug is assigned to libstdc++6. Do you think that
it is a library issue rather than a compiler issue? If you build LO
with an older gcc-9 version, upgrade libstdc++6, and run the test
again (without rebuilding it), does it fail?

If this is due to the compilation step, I would suggest to check LO
with sanitizer options. I also notice that the logs show the that
-fno-enforce-eh-specs option is used, which might also hide issues,
I suppose.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)