adoptium / infrastructure

This repo contains all information about machine maintenance.
Apache License 2.0
85 stars 101 forks source link

java/time/test/java/time/format/TestUTCParse.java failing on multiple platforms for JDK11 #3658

Open Haroon-Khel opened 1 month ago

Haroon-Khel commented 1 month ago

ref https://github.com/adoptium/infrastructure/issues/3614#issuecomment-2187110622

We are seeing java/time/test/java/time/format/TestUTCParse.java fail on multiple platforms. We are not sure if the failure is machine specific (specific to a group of machines) or OS specific.

Ubuntu 2404 JDK11 https://github.com/adoptium/infrastructure/issues/3501#issuecomment-2167782850

UBI8 and 9 JDK11 https://github.com/adoptium/infrastructure/issues/3586#issuecomment-2176380667

We are not seeing it fail on other linux platforms

Mac aarch64 JDK11 Jan 2024 release triage https://github.com/adoptium/aqa-tests/issues/4982#issuecomment-1894967658

smlambert commented 1 month ago

java.lang.AssertionError: expected [UTC−08:00] but found [PST] that was seen on Mac nodes is likely 'a test case that is expecting a certain machine configuration' issue, which means it a poorly written test case which could be addressed by updating the machine Date/Time preferences, but also the testcase itself could be adjusted to handle cases where Date/Time preference is not set to Coordinated Universal Time / UTC, but is instead using local time settings.

I do not see console output of the way in which the test fails on Linux in any of the issues linked. If it is failing with different stacktrace output, we need to understand why.

Haroon-Khel commented 1 month ago

The jobs in the links have expired, Ill run some more to get a fresh output

Haroon-Khel commented 1 month ago

Looking at https://ci.adoptium.net/job/Grinder/10507/console which is running on test-docker-ubi8-x64-1, we're seeing a similar output as the mac issue

15:20:22  test test.java.time.format.TestUTCParse.testUTCOffsetRoundTrip("UTC-01:30"): success
15:20:22  test test.java.time.format.TestUTCParse.testUTCShortNameRoundTrip(): failure
15:20:22  java.lang.AssertionError: expected [UTC−08:00] but found [PST]
15:20:22    at org.testng.Assert.fail(Assert.java:99)
15:20:22    at org.testng.Assert.failNotEquals(Assert.java:1037)
Haroon-Khel commented 1 month ago

Same on ubuntu2404 https://ci.adoptium.net/job/Grinder/10508/console

15:28:22  test test.java.time.format.TestUTCParse.testUTCShortNameRoundTrip(): failure
15:28:22  java.lang.AssertionError: expected [UTC−08:00] but found [PST]
15:28:22    at org.testng.Assert.fail(Assert.java:99)
15:28:22    at org.testng.Assert.failNotEquals(Assert.java:1037)
15:28:22    at org.testng.Assert.assertEqualsImpl(Assert.java:140)
Haroon-Khel commented 1 month ago

It looks like the static containers are already set to UTC. On test-docker-ubuntu2404-x64-1, on which the test failed https://github.com/adoptium/infrastructure/issues/3658#issuecomment-2210979626

root@e80f94f22a13:~# date
Fri Jul  5 15:01:20 UTC 2024
root@e80f94f22a13:~# date +"%Z %z"
UTC +0000
root@e80f94f22a13:~# 
Haroon-Khel commented 1 month ago

Reiterating my comment in https://github.com/adoptium/infrastructure/issues/3614#issuecomment-2218082829

On test-docker-alpine319-x64-4 on which the test passes (https://ci.adoptium.net/job/Grinder/10549/console)

8f585a2be287:/# date
Tue Jul  9 15:57:37 UTC 2024
8f585a2be287:/# date +"%Z %z"
UTC +0000
8f585a2be287:/# 

Same format as https://github.com/adoptium/infrastructure/issues/3658#issuecomment-2211063655

Haroon-Khel commented 1 month ago

Re the ubuntu2404 failures, rerunning the test on ubuntu2204 to check for a difference in failure

test-docker-ubuntu2204-x64-7 https://ci.adoptium.net/job/Grinder/10556/console test-docker-ubuntu2204-armv8-1 https://ci.adoptium.net/job/Grinder/10557/console test-marist-ubuntu2204-s390x-1 https://ci.adoptium.net/job/Grinder/10558/console test-docker-ubuntu2204-ppc64le-3 https://ci.adoptium.net/job/Grinder/10559/console

EDIT: Only failed on s390x with the same error log as https://github.com/adoptium/infrastructure/issues/3658#issuecomment-2210967471

Haroon-Khel commented 1 month ago

In the testcode, the failure is here https://github.com/adoptium/jdk11u/blob/1e3e6877d5c2eb53f9dbb4fc9e045d83975c84b1/test/jdk/java/time/test/java/time/format/TestUTCParse.java#L65

On a passing machine the formatted variable is UTC?08:00 while on a failing one it is PST

sxa commented 1 month ago

EDIT: Only failed on s390x with the same error log as https://github.com/adoptium/infrastructure/issues/3658#issuecomment-2210967471

Noting that this is the only machine of the set that is not a docker image 🤔

Haroon-Khel commented 1 month ago

With Jie's help, taking a closer look at the test code, it does reveal that the test code is not handling the differences in CLDR between machines and that the test assumes CLDR will behave how the test expects it to https://github.com/adoptium/jdk11u/blob/1e3e6877d5c2eb53f9dbb4fc9e045d83975c84b1/test/jdk/java/time/test/java/time/format/TestUTCParse.java#L46

Assuming CLDR's SHORT name for "America/Los_Angeles"
        // produces "UTC\u212208:00"

which is not always the case.

The test is removed altogether in the latest jdk https://github.com/openjdk/jdk/blob/537d20afbff255489a7b1bdb0410b9d1aba715b7/test/jdk/java/time/test/java/time/format/TestUTCParse.java

Either way I do not think this is an infra problem, and perhaps the test should be excluded