-
Bug
-
Resolution: Fixed
-
P3
-
6
-
b15
-
x86
-
linux
-
Not verified
FULL PRODUCT VERSION :
This bug was found in jdk-6u2-ea-src-b02-jrl-12_apr_2007.jar
ADDITIONAL OS VERSION INFORMATION :
This bug is in the Java source
A DESCRIPTION OF THE PROBLEM :
LONGMIN and LONGMAX are not properly guarded, allowing for a potential NullPointerException, or access to a partially instantiated object.
If LONGMIN is null, then both LONGMIN and LONGMAX are instantiated, however in the case of competing threads then it is possible for thread 2 to see LONGMIN as non-null, and LONGMAX as null, resulting in a NPE in BigInteger#compareTo(BigInteger)
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
This is difficult to reproduce as it requires two threads to call longValueExact at the exact same time, however once it is called, then from thereon everyone is safe (on current CPUs anyway)
REPRODUCIBILITY :
This bug can be reproduced rarely.
This bug was found in jdk-6u2-ea-src-b02-jrl-12_apr_2007.jar
ADDITIONAL OS VERSION INFORMATION :
This bug is in the Java source
A DESCRIPTION OF THE PROBLEM :
LONGMIN and LONGMAX are not properly guarded, allowing for a potential NullPointerException, or access to a partially instantiated object.
If LONGMIN is null, then both LONGMIN and LONGMAX are instantiated, however in the case of competing threads then it is possible for thread 2 to see LONGMIN as non-null, and LONGMAX as null, resulting in a NPE in BigInteger#compareTo(BigInteger)
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
This is difficult to reproduce as it requires two threads to call longValueExact at the exact same time, however once it is called, then from thereon everyone is safe (on current CPUs anyway)
REPRODUCIBILITY :
This bug can be reproduced rarely.