JDK-6222207 : BitSet internal invariants may be violated
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-01-27
  • Updated: 2010-04-02
  • Resolved: 2005-02-19
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.
6 b25Fixed
Related Reports
Relates :  
Relates :  
BitSet.java has some invariants, which can be understood best using
this java code:

    private void checkInvariants() {
	assert(wordsInUse == 0 || words[wordsInUse - 1] != 0);
	assert(wordsInUse >= 0 && wordsInUse <= words.length);
	assert(wordsInUse == words.length || words[wordsInUse] == 0);

But these invariants do not always hold, leading to corrupt internal
data corruption and incorrect results.

One manifestation is this program:
import java.util.*;

public class Bug {
    public static void main(String[] args) throws Exception {
	BitSet s = new BitSet();
	System.out.printf("length=%d isEmpty=%b%n", s.length(), s.isEmpty());
length=64 isEmpty=false
when correct is:
length=0 isEmpty=true

###@###.### 2005-1-27 06:57:58 GMT
###@###.### 2005-1-27 07:01:50 GMT

EVALUATION The code is not good about checking its invariants, so they are occasionally violated. Calls to the submitter's checkInvariants should be placed throughout the source code to catch violations. The code has a nasty habit of overshooting a range when the end of a range is near a 64-bit boundary. One must code very carefully to avoid off-by-one error in bit-twiddling code such as this. ###@###.### 2005-1-27 06:57:58 GMT