JDK-6782006 : Reading InputStream of large amount of data results in corrupted data
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_2.5.1
  • CPU: sparc
  • Submitted: 2008-12-08
  • Updated: 2011-02-16
  • Resolved: 2009-01-08
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.6.0_11"
Java(TM) SE Runtime Environment (buld 1.6.0_11-b03)
Java Hotspot(TM) Server VM (build 11.0-b16 mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Sparc Solaris 10

A DESCRIPTION OF THE PROBLEM :
Using a FileInputStream to read and process the bytes of a file, after a while it appears that the inputstream and buffer to hold what was read are out of sync.  The problem finally becomes apparent when trying to convert a String to an int.  However, because the buffer is at a different location than expected, a NumberFormatException is thrown (the data is not not an String version of an int).

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
The issue was introduced with build 10 of version 1.6.  The previous build 7 of version 1.6 works correctly.

I do have a sample application that demonstrates the issue.  It consistently demonstrates the issue.  However, the issue seems to be related to a large input stream.  Therefore, my sample application provides a large data file (4MB).


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Although the data is in a very domain-specific format, the issues is presented when a series of bytes are read as a String and then the String is converted to an int.  The expected result would be an int that was represented by the String.
ACTUAL -
With version 1.6.0_07, the byte array is correctly converted to String to int.
With version 1.6.0_10 or 1.6.0_11, the byte array is pointing to incorrect data.

The issue is frequently consistent in the place in which the issue is manifest.  However, it is not always.  In fact, debugging the application will affect where the issue is manifest -- if at all.  If I slow down the processing or reading of the inputstream, the problem is rarely occurs.  But it always occurs when running the application.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Here is the stack trace:

java.lang.NumberFormatException: For input string: "...."
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:447)
at java.lang.Integer.parseInt(Integer.java:497)
...

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
As mentioned before, I do have a sample application (400 lines) that demonstrates the issue.  The problem is that is it dependent on an external data file (4MB).  Is there a way that I can send both the java source file and the data file?
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
The only workaround is to use a build 7 or version 1.6.  Build 10 and 11 both demonstrate the issue.

Release Regression From : 6u7
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.

Comments
EVALUATION Fixed with 6686791: Side effect in NumberFormat tests with -server -Xcomp (all platforms, 6u5 perf release b01) The fix will be available in jdk6u14 with HS14.
08-01-2009

EVALUATION Introduced with the next push: 20070719212032.jrose.6337834 Fixed 6337834: JVM should remove unneeded zeroing during object allocation Fixed 6506252: Do not mark cards for objects known to be in the young gen Fixed 6506313: TLS shouldn't be rematerializable on win32 Partial 6525691: miscellaneous compiled code improvements Partial 6579652: repair to split_through_phi (temporary fix; putback was blocked) Reviewed by: Vladimir, Steve Work deferred after this putback: - reduce register pressure on 64-bit machines from I2L conversions near allocation sites
08-01-2009

EVALUATION This does appear to be a regression in the server VM in HS 11 (6u10 ships with HS 11-b15). I checked HS 14 and the problem does not reproduce. Working back it seems to have been fixed between HS 12.0-b01 and 12.0-b03. Re-assigning to C2 team so that it can be analyzed and closed.
09-12-2008

WORK AROUND Use client VM (-client).
09-12-2008

EVALUATION It's reproducible with "server" vm only. Test case works fine when using "client"vm.
08-12-2008