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

[Dmitry Shachnev]

Version: 9.2.1-16

On Thu, Oct 31, 2019 at 10:32:05PM +0100, Rene Engelhard wrote:
> > The fix is now in -16.
>
> Good. Can confirm. You can close the bug.

Doing that now to let gcc-9 migrate (when it is built on mips*).

Thanks everyone for your work!

--
Dmitry Shachnev


signature.asc
Description: PGP signature

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)

[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.

Re: 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]

>> 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.

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.

Re: 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)

Re: 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.

Re: 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)

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

[Rene Engelhard]

Hi,

On Mon, Oct 28, 2019 at 10:39:37PM +0100, Matthias Klose wrote:
> > but let's try to work together to fix the current situation.

That's what I tried, but... Disabling make check (as will be done)
is not "fix"ing but just hiding it.

> my moreinfo tag was removed, and I'm not interested in a bts war, which rene
> likes to start very often. and, no, I won't start citing rene's private
> messages here.

You imply they were bad. I can cite them myself if you want. There wasn't bad
messages, it was basically the same which was in the bug but in german.

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.

Regards,

Rene

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

[Rene Engelhard]

Hi,

On Mon, Oct 28, 2019 at 10:39:37PM +0100, Matthias Klose wrote:
> On 28.10.19 22:17, Paul Gevers wrote:
> > Dear all,
> > 
> > The visible progress on this bug report stopped several days ago. I'd
> > like to try an get it a bit further. I'm expecting frustration on all
> > sides,
> 
> yes, and side note that I will use the same terms of "several days ago" for
> a three day silence including two non-work days.
> 
> > but let's try to work together to fix the current situation.
> 
> my moreinfo tag was removed, and I'm not interested in a bts war, which rene

Because you got the needed info. "Run debian/tests/smoketest". I don't
have more info, and simply don't have time or knowledge on C++
exceptions to handle this either way.

> likes to start very often. and, no, I won't start citing rene's private

*You* reassigned the bug back with "with what rationale" and failed
to read the bug log that I mentioned the gcc upload and the exception
failure and still insisted on Dmitrys dates in the subject which I said
to be non-true in the first message of the bug.

You started the BTS war, not me. If you read the bug you could have just
kept it at gcc without any BTS war.

> > Matthias, did you have time to look into the issue? Have you discovered
> > anything that is worth knowing already? If not, do you intent to work on
> > this soon. I noticed you uploaded a new version that doesn't address
> > this RC bug, for the reason I mentioned above, could you please refrain
> > from uploading new versions unless critical issues that aren't present
> > in testing are fixed in those uploads until a version of gcc-9 migrates?
> 
> I asked for a test case, not a multi-hour build and a multi-hour test run.

And I said it exceeds my knowledge.

debian/tests/smoketest is not a "multi hour test run". It builds part of LO,
yes, but it definitely is not multi hour. It is actually ONE test.

See the script.

The autopktest actually times itself out when it takes too long (which doesn't 
happen
even on older hardware.)

> Sure I can start looking at this myself, but I don't have the LO domain
> knowledge anymore.  Yes, I could start bisecting, however that doesn't sound

Neither do I. I just maintain and build this. Let alone time-wise...
Regards.

Rene

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

[Rene Engelhard]

Hi,

On Mon, Oct 28, 2019 at 10:17:49PM +0100, Paul Gevers wrote:
> Rene, I really appreciate the fact that libreoffice has an extensive
> test suite. But just to get options on the table can you please tell us
> how severe this particular failure is? In other words, how much is this
> telling you about libreoffice? I think the failure is "just" that you

No idea. The test doesn't run. No more info. And the failure is beyond
my skills anyway.

> can't compile a test that used to be able to compile. And you suspect
> that the libreoffice test may not be the only code that breaks.

No, I didn't say that.

Actually, I disabled running make check already for the next upload.
"at scheduled" for Thursday.

Regards,

Rene

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

[Matthias Klose]

On 28.10.19 22:17, Paul Gevers wrote:

Dear all,

The visible progress on this bug report stopped several days ago. I'd
like to try an get it a bit further. I'm expecting frustration on all
sides,


yes, and side note that I will use the same terms of "several days ago" for a 
three day silence including two non-work days.



but let's try to work together to fix the current situation.


my moreinfo tag was removed, and I'm not interested in a bts war, which rene 
likes to start very often. and, no, I won't start citing rene's private messages 
here.



Matthias, did you have time to look into the issue? Have you discovered
anything that is worth knowing already? If not, do you intent to work on
this soon. I noticed you uploaded a new version that doesn't address
this RC bug, for the reason I mentioned above, could you please refrain
from uploading new versions unless critical issues that aren't present
in testing are fixed in those uploads until a version of gcc-9 migrates?


I asked for a test case, not a multi-hour build and a multi-hour test run. Sure 
I can start looking at this myself, but I don't have the LO domain knowledge 
anymore.  Yes, I could start bisecting, however that doesn't sound very effective.


My main effort however now is to restore native and cross builds, an issue I 
didn't cause myself and I'd like to see fixed.


Matthias

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

[Paul Gevers]

Dear all,

The visible progress on this bug report stopped several days ago. I'd
like to try an get it a bit further. I'm expecting frustration on all
sides, but let's try to work together to fix the current situation. In
case you aren't aware, the fact that gcc-9 hasn't migrated to testing in
the last couple of weeks is starting to impact quite some uploads and
transitions (search for "gcc-9 (not considered)" in
https://release.debian.org/britney/update_excuses.html)

Rene, I really appreciate the fact that libreoffice has an extensive
test suite. But just to get options on the table can you please tell us
how severe this particular failure is? In other words, how much is this
telling you about libreoffice? I think the failure is "just" that you
can't compile a test that used to be able to compile. And you suspect
that the libreoffice test may not be the only code that breaks.

Matthias, did you have time to look into the issue? Have you discovered
anything that is worth knowing already? If not, do you intent to work on
this soon. I noticed you uploaded a new version that doesn't address
this RC bug, for the reason I mentioned above, could you please refrain
from uploading new versions unless critical issues that aren't present
in testing are fixed in those uploads until a version of gcc-9 migrates?

Paul



signature.asc
Description: OpenPGP digital signature

libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector) (was: Re: Bug#943401: libreoffice: Autopkgtests are failing since 2019-10-21)

[Rene Engelhard]

Hi,

On Fri, Oct 25, 2019 at 06:33:13PM +0200, Rene Engelhard wrote:
> On Fri, Oct 25, 2019 at 06:25:43PM +0200, Matthias Klose wrote:
> > [...] -12 was uploaded on Oct 23, but you say
> > that the tests started failing on Oct 21.
> 
> No, the submitter did which clearly was wrong. Please read the bug,
> I said that at my very first message.

Which is why I reitled the bug already ...

> > So why do you think this is related to gcc-9?
> 
> Because the exception-related message started on Oct 24. See
> https://ci.debian.net/packages/libr/libreoffice/unstable/amd64/:
> 
> https://ci.debian.net/data/packages/unstable/amd64/libr/libreoffice/3241554.log
> oh, gcc-9 9.2.1-12.
> Log:
> https://ci.debian.net/data/autopkgtest/unstable/amd64/libr/libreoffice/3241554/log.gz

... to what we have here. (yes, this thread has the old subject, but
that doesn't matter for the bug contents.)

Changing subject now...

Regards,

Rene