JDK-8022224 : Rare bug in JISAutodetect charset detected by FindDecoderBugs test
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio.charsets
  • Affected Version: 8,9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-08-05
  • Updated: 2024-03-26
  • Resolved: 2015-08-06
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 9
9 b77Fixed
Related Reports
Relates :  
JDK-7067676 - test/sun/nio/cs/FindDecoderBugs.java failing intermittently
Relates :  
JDK-8080658 - Update sun/nio/cs/FindDecoderBugs.java to use random number generator library
Relates :  
JDK-8078334 - Mark regression tests using randomness
Relates :  
JDK-8080658 - Update sun/nio/cs/FindDecoderBugs.java to use random number generator library
Description
Observed same-binary test failure(s) with observed probability of failure:

TESTFAIL:sun/nio/cs/FindDecoderBugs.java, 0.0021598272138228943
Comments
URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a89761ed254b User: lana Date: 2015-08-11 20:21:52 +0000
11-08-2015
URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a89761ed254b User: sherman Date: 2015-08-06 17:13:32 +0000
06-08-2015
The failure is triggered when (1) x-JISAutoDetect pre-scan/decode the leading ascii, AND (2) the iso-2022-jp decoder parses the escape sequences, switch into a specific charset but without any real bytes to decode. In this scenario, decode with enough space left in output CharBuffer returns underflow and decode with only the number of space for the leading ascii characters returns overflow. Such as the following test. Charset cs = Charset.forName("x-JISAutoDetect"); ByteBuffer bb = ByteBuffer.wrap(new byte[] { 0x86, 0x1b, 0x24, 0x40 }); CharBuffer cb = CharBuffer.wrap(new char[10]); System.out.println(cs.newDecoder().decode(bb, cb, false)); bb.rewind(); cb.clear().limit(1); System.out.println(cs.newDecoder().decode(bb, cb, false));
04-08-2015
On further examination it would be best to close this bug for now. We can re-open it if there are any further sightings of this issue.
08-12-2013
Release team: Approved for deferral.
06-12-2013
SQE: OK for defer
05-12-2013
I've added 8-defer-request to this bug as we are chasing a ghost. To my knowledge, there hasn't been any sighting of this issue in any of the recent same-binary runs (3 platforms), also no sightings in TL nightly testing or JPRT for several months. All instrumented runs that have been done to try duplicate this issue have not have yielded anything useful (the tests passes every time). This is really a case where we need to capture the generated code when running in JPRT or Aurora so that it can be used in post failure analysis. So we ask that this one be deferred to tbd_minor for now.
04-12-2013
I've removed the teststabilization label from this bug as the little evidence to date does not support the theory that this is an unstable test.
30-11-2013
See JDK-7067676 for a possible dup. Each time that we've looked at this we have suspected a hotspot bug. To my knowledge we haven't had any sightings for at least 6 months.
30-11-2013
I had a sighting of this a few days ago on solaris-sparcv9 (in JPRT). It's likely we are chasing a hotspot bug.
15-08-2013