Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.2, 2.2.1, 2.2.4, 2.2.5
    • Fix Version/s: 2.2.7
    • Component/s: jackrabbit-core
    • Labels:
      None

      Description

      When a long value assigned to a property is too big, when restarting the server the value become 0 !!

      The test pass with versions 1.6.4 and 2.0

      1. LongValueTest.java
        2 kB
        Antoine Brochard

        Activity

        Hide
        Stefan Guggisberg added a comment -

        regression of JCR-2762.

        test case:

        any long value > 0x3FFFFFFFFFFFFFFF (i.e. with any of the 2 most significant bits set)
        causes an overflow on deserialization.

        this obviously also includes Long.MAX_VALUE and Long.MIN_VALUE...

        example:
        long test = 0x3FFFFFFFFFFFFFFFL;

        BundleWriter.writeVarLong(test);
        test == BundleReader.readVarLong() // => ok

        test++;
        BundleWriter.writeVarLong(test);
        => BundleReader.readVarLong() returns 0

        Show
        Stefan Guggisberg added a comment - regression of JCR-2762 . test case: any long value > 0x3FFFFFFFFFFFFFFF (i.e. with any of the 2 most significant bits set) causes an overflow on deserialization. this obviously also includes Long.MAX_VALUE and Long.MIN_VALUE... example: long test = 0x3FFFFFFFFFFFFFFFL; BundleWriter.writeVarLong(test); test == BundleReader.readVarLong() // => ok test++; BundleWriter.writeVarLong(test); => BundleReader.readVarLong() returns 0
        Hide
        Jukka Zitting added a comment -

        Ouch, good catch! Fixed in revision 1100286 along with tests also for some other value types.

        Luckily this is not a serialization bug so none of the stored data itself is compromized unless used as input for copies or further calculations. However, we'll need to backport this fix to the 2.2 branch and warn people not to rely on large values read from the repository until this fix has been applied. I'll take care of that first thing next week.

        Show
        Jukka Zitting added a comment - Ouch, good catch! Fixed in revision 1100286 along with tests also for some other value types. Luckily this is not a serialization bug so none of the stored data itself is compromized unless used as input for copies or further calculations. However, we'll need to backport this fix to the 2.2 branch and warn people not to rely on large values read from the repository until this fix has been applied. I'll take care of that first thing next week.
        Hide
        Jukka Zitting added a comment -

        Merged to the 2.2 branch in revision 1127054.

        Show
        Jukka Zitting added a comment - Merged to the 2.2 branch in revision 1127054.

          People

          • Assignee:
            Jukka Zitting
            Reporter:
            Antoine Brochard
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development