jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <j...@apache.org>
Subject [jira] [Created] (JCR-3581) Incorrect bitwise arithmetic in BitsetENTCacheImpl.BitsetKey.compareTo implementation - wrong bit mask value used
Date Tue, 23 Apr 2013 15:03:15 GMT
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

Mime
View raw message