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

[Langer, Christoph]

Hi Thomas,

thanks for your review. I updated the comment lines: http://cr.openjdk.java.net/~clanger/webrevs/8200286.1/

Best regards
Christoph

From: Thomas Stüfe <thomas.stuefe at gmail.com>
Sent: Donnerstag, 21. März 2019 11:32
To: Langer, Christoph <christoph.langer at sap.com>
Cc: 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/

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/ff6430d4/attachment-0001.html>