Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

JTReg test fail - Linux s390 : java/lang/String/UnicodeCasingTest.java #4597

Closed
ben-walsh opened this issue Feb 5, 2019 · 12 comments · Fixed by #4688
Closed

JTReg test fail - Linux s390 : java/lang/String/UnicodeCasingTest.java #4597

ben-walsh opened this issue Feb 5, 2019 · 12 comments · Fixed by #4688
Assignees
@fjeremic
Labels
arch:z comp:jit test failure
Projects
JTReg failures

Comments

@ben-walsh
Copy link
Contributor

ben-walsh commented Feb 5, 2019 •
edited
Loading

Consistent multiple failures of test https://github.com/ibmruntimes/openj9-openjdk-jdk11/blob/openj9/test/jdk/java/lang/String/UnicodeCasingTest.java are observed on Linux s390 of the form ...

Testing on en_NU locale....
toUpperCase() failed.
	Original: 0xFF 
	Got:      0xFF 
	Expected: 0x178

See https://ci.adoptopenjdk.net/view/Test_openjdk/job/openjdk11_j9_openjdktest_s390x_linux/140/testReport/junit/java_lang_String_UnicodeCasingTest/java/UnicodeCasingTest

No such failures are observed on other platforms ...
e.g. Linux PPC ...
https://ci.adoptopenjdk.net/view/Test_openjdk/job/openjdk11_j9_openjdktest_ppc64le_linux/130/testReport/java_lang_String_UnicodeCasingTest/java/UnicodeCasingTest
e.g. Windows ...
https://ci.adoptopenjdk.net/view/Test_openjdk/job/openjdk11_j9_openjdktest_x86-64_windows/130/testReport/java_lang_String_UnicodeCasingTest/java/UnicodeCasingTest

It seems to be all the locale variants of English that are failing, nothing else.
@pshipton pshipton added this to To do in JTReg failures via automation Feb 5, 2019
@pshipton
Copy link
Member

pshipton commented Feb 5, 2019

@fjeremic

@fjeremic
Copy link
Contributor

fjeremic commented Feb 6, 2019

Can we get some machine information? Which processor did this test run and fail on? Going to try to reproduce manually if I can find the documentation on how to do so.

@fjeremic
Copy link
Contributor

fjeremic commented Feb 6, 2019

I cannot reproduce UnicodeCasingTest on my z13 using the latest nightly build of JDK11. We'll need more information on the machine this ran on. It is likely a JIT issue given the test runs fine on my machine.

@fjeremic
Copy link
Contributor

fjeremic commented Feb 6, 2019

I can reproduce on an internal grinder. Going to try using the test infrastructure to reproduce locally too if I can. If not I can try to debug via grinders.

@ben-walsh
Copy link
Contributor Author

From the top of this page - https://ci.adoptopenjdk.net/view/Test_openjdk/job/openjdk11_j9_openjdktest_s390x_linux/140 ... the test was executed on test-marist-ubuntu1604-s390x-1. The details for this test machine can be found at https://ci.adoptopenjdk.net/computer/test-marist-ubuntu1604-s390x-1.
I will discuss with @sxa555 to obtain access sufficient to gain the information you require on the machine.

@ben-walsh
Copy link
Contributor Author

ben-walsh commented Feb 7, 2019 •
edited
Loading

I've got this ...

$ uname -a
Linux test-marist-ubuntu1604-s390x-1.adoptopenjdk.net 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:21:31 UTC 2018 s390x s390x s390x GNU/Linux

$ cat /proc/cpuinfo
vendor_id       : IBM/S390
# processors    : 4
bogomips per cpu: 20325.00
features	: esan3 zarch stfle msa ldisp eimm dfp etf3eh highgprs vx 
cache0          : level=1 type=Data scope=Private size=128K line_size=256 associativity=8
cache1          : level=1 type=Instruction scope=Private size=96K line_size=256 associativity=6
cache2          : level=2 type=Data scope=Private size=2048K line_size=256 associativity=8
cache3          : level=2 type=Instruction scope=Private size=2048K line_size=256 associativity=8
cache4          : level=3 type=Unified scope=Shared size=65536K line_size=256 associativity=16
cache5          : level=4 type=Unified scope=Shared size=491520K line_size=256 associativity=30
processor 0: version = FF,  identification = 010000,  machine = 2964
processor 1: version = FF,  identification = 020000,  machine = 2964
processor 2: version = FF,  identification = 030000,  machine = 2964
processor 3: version = FF,  identification = 040000,  machine = 2964

... through a temporary account on the test machine.

Does that cover what you need ? @fjeremic

@fjeremic
Copy link
Contributor

fjeremic commented Feb 7, 2019

Does that cover what you need ? @fjeremic

Thanks that's what I needed. Odd that I cannot reproduce on my z13. Though I've just taken the test and compiled as is. Perhaps some of the options make a difference. Looking into it now and trying to reproduce via the testing makefiles.

@fjeremic fjeremic self-assigned this Feb 8, 2019
@fjeremic
Copy link
Contributor

fjeremic commented Feb 8, 2019

Short update is that this is definitely a Z codegen bug in our vector uppercase/lowercase intrinsic. We do have unit tests for this so I'm not sure how it has escaped this far. Will be fixing shortly and looking into why our unit tests did not catch this.

@fjeremic fjeremic mentioned this issue Feb 11, 2019
Merged
@fjeremic
Copy link
Contributor

@ben-walsh FYI the first link in the description is very misleading. It points to the java/lang/Character testing while the test that failed is in the java/lang/String testing (your second link). This is why my manual attempt at locally reproducing was not working. I was testing the wrong thing!

@ben-walsh
Copy link
Contributor Author

@fjeremic Apologies. My mistake.

@ben-walsh ben-walsh changed the title JTReg test fail - Linux s390 : java/lang/Character/UnicodeCasingTest.java JTReg test fail - Linux s390 : java/lang/String/UnicodeCasingTest.java Feb 12, 2019
@ben-walsh
Copy link
Contributor Author

Title and links in description corrected accordingly.

fjeremic added a commit to fjeremic/openj9 that referenced this issue Feb 12, 2019
@fjeremic
Fix caseConversionHelper to check for 0xB5, 0xDF, and 0xFF corner cases
38f9961 
In eclipse-openj9#4597 we identified cases on which `toUpperCase` fails on Linux on
Z. This is due to some faulty login in the evaluator for these
intrinsics on Z. Bugs seem to have been introduced in eclipse-openj9#2318 for certain
characters. Namely the test in eclipse-openj9#4597 fails to convert the `\u00FF`
character. The bug is obvious, since `toUpperCase` of such a character
cannot be handled and the JIT evaluator determines the invalid
character range by checking if the character is greater than 0xFF, but
it should be checking if greater than or equal to.

In addition the compressed String evaluator also fails on 0xB5 as
determined by the unit tests. Both issues are fixed.

Fixes: eclipse-openj9#4597

Signed-off-by: Filip Jeremic <fjeremic@ca.ibm.com>
@fjeremic
Copy link
Contributor

Fix is in #4688 and is waiting for a committer to pick it up. Thanks for letting us know about this bug!

JTReg failures automation moved this from To do to Done Mar 4, 2019
@0xdaryl 0xdaryl added arch:z and removed comp:jit:z labels Jun 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@fjeremic fjeremic

Labels
arch:z comp:jit test failure
Projects
JTReg failures
  
Done
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix vectorized toLowerCase and toUppercase intrinsics on Z fjeremic/openj9
4 participants
@fjeremic @0xdaryl @pshipton @ben-walsh