[jira] [Created] (JCR-3581) Incorrect bitwise arithmetic in BitsetENTCacheImpl.BitsetKey.compareTo implementation - wrong bit mask value used

["Ate Douma (JIRA)" <ji...@apache.org>]

Ate Douma created JCR-3581:
------------------------------

             Summary: Incorrect bitwise arithmetic in BitsetENTCacheImpl.BitsetKey.compareTo implementation - wrong bit mask value used  
                 Key: JCR-3581
                 URL: https://issues.apache.org/jira/browse/JCR-3581
             Project: Jackrabbit Content Repository
          Issue Type: Bug
          Components: jackrabbit-core, jackrabbit-jcr2spi
    Affects Versions: 2.6, 2.7
            Reporter: Ate Douma


The BitsetKey class encodes Names bitwise in one or more long values.

For its Comparable.compareTo implementation, the long value(s) are compared first by ">>> 32" shifting to compare the higher bits, and if that equals out by comparing the lower 32 bits.

The bug is in the latter part: instead of masking off the higher 32 bits using "& 0x0ffffffffL", the current code is masking the higher 48 bits using "& 0x0ffffL", as shown in snippet below from the current compareTo implementation:

                    long w1 = adr<bits.length ? bits[adr] : 0;
                    long w2 = adr<o.bits.length ? o.bits[adr] : 0;
                    if (w1 != w2) {
                        // some signed arithmetic here
                        long h1 = w1 >>> 32;
                        long h2 = w2 >>> 32;
                        if (h1 == h2) {
                            h1 = w1 & 0x0ffffL;
                            h2 = w2 & 0x0ffffL;
                        }
                        return Long.signum(h2 - h1);
                    }

As result of this error many possible keys cannot and will not be stored in the BitsetENTCacheImpl private TreeSet<Key> sortedKeys: only one key for every key with a value between 0x0ffffL and 0x0ffffffffL (for *each* long field) will be stored.
Note that such 'duplicate' keys however will be used and stored in the other BitsetENTCacheImpl private HashMap<Key, EffectiveNodeType> aggregates.
As far as I can tell this doesn't really 'break' the functionality, but can lead to many redundant and unnecessary (re)creation of keys and entries in the aggregates map.

The fix of course is easy but I will also provide a patch file with fixes for the two (largely duplicate?) BitsetENTCacheImpl implementations (jackrabbit-core and jackrabbit-jcr2spi).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira