JDK-8193597 : sun/nio/cs/TestStringCoding.java fails intermittently with getBytes(csn) failed -> GBK
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 10
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2017-12-15
  • Updated: 2018-04-05
  • Resolved: 2018-01-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10 JDK 11
10 b40Fixed 11Fixed
Related Reports
Relates :  
JDK-8186027 - C2: loop strip mining
Description
I suspect it's related to the specified test machine because it only failed once:
----------System.out:(8/267)----------
Testing(sm=false) Big5....done!
Testing(sm=false) Big5-HKSCS....done!
Testing(sm=false) CESU-8....done!
Testing(sm=false) EUC-JP....done!
Testing(sm=false) EUC-KR....done!
Testing(sm=false) GB18030....done!
Testing(sm=false) GB2312....done!
Testing(sm=false) GBK....
----------System.err:(14/892)----------
java.lang.RuntimeException: getBytes(csn) failed  -> GBK
	at TestStringCoding.testGetBytes(TestStringCoding.java:164)
	at TestStringCoding.main(TestStringCoding.java:82)
Comments
yes, agree ILW = HHM = P1
11-01-2018
Fix is: diff --git a/src/hotspot/share/opto/loopnode.cpp b/src/hotspot/share/opto/loopnode.cpp --- a/src/hotspot/share/opto/loopnode.cpp +++ b/src/hotspot/share/opto/loopnode.cpp @@ -1489,8 +1489,8 @@ } else { new_limit = igvn->transform(new SubINode(iv_phi, min)); } - igvn->replace_input_of(inner_cle->cmp_node(), 2, new_limit); Node* cmp = inner_cle->cmp_node()->clone(); + igvn->replace_input_of(cmp, 2, new_limit); Node* bol = inner_cle->in(CountedLoopEndNode::TestValue)->clone(); cmp->set_req(2, limit); bol->set_req(1, igvn->transform(cmp));
11-01-2018
$ javac --add-exports java.base/sun.nio.cs.=ALL-UNNAMED TestCase.java $ java --add-exports java.base/sun.nio.cs.=ALL-UNNAMED TestCase Found the reproted test failure issue introduced with jdk10-b36 and is also reproducible with latest jdk/jdk sources. Failure is not present with -XX:LoopStripMiningIter=0. So it seems root cause could be 'C2 loop strip mining' enhancement task JDK-8186027 fix. initial ILW = test failure, regression; one reproducible case reported, seems rare; disable loop strip mining = HMM = P2 Hi, [~roland], request your help to check this one.
10-01-2018
It appears we have a vm/compile bug some where. Test case: http://cr.openjdk.java.net/~sherman/8193597/TestCase.java javac --add-exports java.base/sun.nio.cs.=ALL-UNNAMED TestCase.java java --add-exports java.base/sun.nio.cs.=ALL-UNNAMED TestCase The code triggers the failure is at sun.nio.cs.DoubleByte.Encoder.encodeFromUTF16(). It appears following code which is to detect if we have a pair of surrogates is "skipped/optimized away" by the compiler. if (Character.isHighSurrogate(c) && sp < sl && Character.isLowSurrogate(StringUTF16.getChar(src, sp))) { sp++; } The problem can be workaround/solved if I declare the local variable "c" and "bb" outside the while loop as showed in the webrev. http://cr.openjdk.java.net/~sherman/8193597/webrev/src/java.base/share/classes/sun/nio/cs/DoubleByte.java.sdiff.html The "System.out.printf(...)" is only to help the debugging. Move to compiler for further investigation.
10-01-2018
closed as "cannot reproduce" for now. please open it again if it appears again. gbk is a src-generated charset, which shares its implementation with dozen of other dbcs charsets, it is abnormal only the gbk fails in such testing.
03-01-2018