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

[Jonathan Gibbons]

Looks good, and better than the earlier sleep calls.

An alternative strategy, in case there is ever any issue setting the 
time of the file, would be a conditional/iterative sleep until the time 
to write a second file is observably different from the time to write an 
initial file.

-- Jon


On 03/21/2019 11:53 AM, Thomas Stüfe wrote:
> Looks good now.
>
> ..Thomas
>
> On Thu, Mar 21, 2019 at 5:15 PM Langer, Christoph 
> <christoph.langer at sap.com <mailto:christoph.langer at sap.com>> wrote:
>
>     Hi Thomas,
>
>     thanks for your review. I updated the comment lines:
>     http://cr.openjdk.java.net/~clanger/webrevs/8200286.1/
>     <http://cr.openjdk.java.net/%7Eclanger/webrevs/8200286.1/>
>
>     Best regards
>
>     Christoph
>
>     *From:*Thomas Stüfe <thomas.stuefe at gmail.com
>     <mailto:thomas.stuefe at gmail.com>>
>     *Sent:* Donnerstag, 21. März 2019 11:32
>     *To:* Langer, Christoph <christoph.langer at sap.com
>     <mailto:christoph.langer at sap.com>>
>     *Cc:* compiler-dev at openjdk.java.net
>     <mailto:compiler-dev at openjdk.java.net>
>     *Subject:* Re: RFR(S): 8200286: (testbug) MOptionTest test fails
>     with java.lang.AssertionError: Classfiles too old!
>
>     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 <mailto: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
>         <mailto:compiler-dev at openjdk.java.net>'
>         <compiler-dev at openjdk.java.net
>         <mailto:compiler-dev at openjdk.java.net>>
>         *Cc:* Zeller, Arno <arno.zeller at sap.com
>         <mailto: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/
>         <http://cr.openjdk.java.net/%7Eclanger/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/0921c930/attachment-0001.html>