RFR(S): 8200286: (testbug) MOptionTest test fails with java.lang.AssertionError: Classfiles too old!

[Thomas Stüfe]

Looks reasonable. I am not sure I understand the purpose of the 2 second
waits so I cannot comment what their removal does.

Comment: please loose the commas and the trailing "otherwise"

Thanks! Thomas

On Wed, Mar 20, 2019 at 9:41 AM Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi,
>
>
>
> Ping…
>
>
>
> Any comments/reviews on this test fix?
>
>
>
> Thanks
>
> Christoph
>
>
>
> *From:* Langer, Christoph
> *Sent:* Freitag, 15. März 2019 14:25
> *To:* 'compiler-dev at openjdk.java.net' <compiler-dev at openjdk.java.net>
> *Cc:* Zeller, Arno <arno.zeller at sap.com>
> *Subject:* RFR(S): 8200286: (testbug) MOptionTest test fails with
> java.lang.AssertionError: Classfiles too old!
>
>
>
> Hi,
>
>
>
> please review a fix proposal for an intermittent error in
> test/langtools/tools/javac/modules/MOptionTest.java.
>
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8200286
>
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8200286.0/
>
>
>
> The issue has been reported already a while ago but was closed as not
> reproducible/won’t fix. However, we’ve encountered this issue quite often
> on a linuxppc64 test machine in our ci infrastructure. Here are links to
> failed test jobs:
>
>
>
> jdk11u:
>
>
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/27/
>
>   ->jtr:
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/27/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
>
>
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/26/
>
>     ->jtr:
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/26/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
>
>
>
> jdk12:
>
>
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/5/
>
>     ->jtr:
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/5/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
>
>
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/3/
>
>     ->jtr:
> https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/3/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
>
> jdk:
>
>
> https://ci.sapmachine.io/view/Branch%20Builds/job/build--branch-linux_ppc64/4/
>
>     ->jtr:
> https://ci.sapmachine.io/view/Branch%20Builds/job/build--branch-linux_ppc64/4/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
>
>
>
> The analysis done in the bug by Jiangli seems to be true. There is some
> imprecision in time resolution (maybe rounding issue, maybe os inaccuracy)
> where it can happen that the class file created by the java compiler has an
> earlier timestamp than the original source file.
>
>
>
> What I did to overcome this is to date back the .java file to be compiled
> by one second before doing the compilation which will create a class file
> with the current time stamp. This should make sure that the .java file
> doesn’t have a newer timestamp than the .class file.
>
> I can do that because the test thread had waited for 2 seconds before
> doing the compilation. In fact, I have removed another 2 second wait
> because I don’t think it is needed at that place since the test had already
> waited 2 seconds before testing a noop compilation due to unchanged
> timestamps.
>
>
>
> I guess this is certainly not perfect but it should stabilize this test
> and to me it seems pragmatic.
>
>
>
> I have already added this fix to our (SapMachine) code base and have not
> observed this error after that and didn’t run into regressions either.
>
>
>
> Thanks
>
> Christoph
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190321/d5a06ed0/attachment.html>