Derby
  1. Derby
  2. DERBY-4081

BTreeController.comparePreviousRecord() may fail to release latch on left-most leaf

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.4.2.0
    • Fix Version/s: 10.4.2.1, 10.5.3.1, 10.6.1.0
    • Component/s: Store
    • Labels:
      None
    • Urgency:
      Normal

      Description

      If comparePreviousRecord() is called on some other leaf page than the left-most leaf, and all the rows to the left of the current position are deleted so that the position is moved all the way to slot 0 on the left-most leaf, comparePreviousRecord() will return without releasing the latch on the left-most leaf. Only the leaf on which comparePreviousRecord() is called should be latched when the method returns.

      Since comparePreviousRecord() currently fails to continue after finding a deleted row, this bug is not possible to expose until DERBY-4028 is fixed.

      1. derby-4081-1b.diff
        3 kB
        Knut Anders Hatlen
      2. derby-4081-1a.diff
        1 kB
        Knut Anders Hatlen

        Activity

        Hide
        Knut Anders Hatlen added a comment -

        I believe that the attached patch solves the problem. It releases the latch on the previous page earlier, so that it is already released when the method detects that it is positioned before the left-most leaf and returns NO_MATCH. This is the same thing as compareNextRecord() does when it detects that it's positioned after the right-most leaf.

        Show
        Knut Anders Hatlen added a comment - I believe that the attached patch solves the problem. It releases the latch on the previous page earlier, so that it is already released when the method detects that it is positioned before the left-most leaf and returns NO_MATCH. This is the same thing as compareNextRecord() does when it detects that it's positioned after the right-most leaf.
        Hide
        Rick Hillegas added a comment -

        July 2, 2009: Marked PatchAvailable and assigned normal urgency.

        Show
        Rick Hillegas added a comment - July 2, 2009: Marked PatchAvailable and assigned normal urgency.
        Hide
        Knut Anders Hatlen added a comment -

        Thanks for the reminder, Rick.

        I think I've found a way to expose this problem now. Just continuously executing "insert into t values 0" followed by "delete from t", where T.X is unique nullable and with auto-commit off, consistently hangs on the 372nd iteration.

        On 10.5.1.1 that repro fails with a WaitError (DERBY-4097). It does not expose the problem on 10.4.2.0 or earlier since DERBY-4028 hides the problem by stopping the check for duplicates too early.

        Show
        Knut Anders Hatlen added a comment - Thanks for the reminder, Rick. I think I've found a way to expose this problem now. Just continuously executing "insert into t values 0" followed by "delete from t", where T.X is unique nullable and with auto-commit off, consistently hangs on the 372nd iteration. On 10.5.1.1 that repro fails with a WaitError ( DERBY-4097 ). It does not expose the problem on 10.4.2.0 or earlier since DERBY-4028 hides the problem by stopping the check for duplicates too early.
        Hide
        Knut Anders Hatlen added a comment -

        Attached a new patch (1b) with no changes from 1a except that a test case has been added to NullableUniqueConstraintTest. The test case never completes without the fix because it runs into a self-deadlock (or actually a livelock) caused by the latch it forgot to release. The test case runs and completes successfully with the fix.

        Show
        Knut Anders Hatlen added a comment - Attached a new patch (1b) with no changes from 1a except that a test case has been added to NullableUniqueConstraintTest. The test case never completes without the fix because it runs into a self-deadlock (or actually a livelock) caused by the latch it forgot to release. The test case runs and completes successfully with the fix.
        Hide
        Knut Anders Hatlen added a comment -

        Derbyall and suites.All ran cleanly with the patch.

        Show
        Knut Anders Hatlen added a comment - Derbyall and suites.All ran cleanly with the patch.
        Hide
        Knut Anders Hatlen added a comment -

        Committed revision 805696. I will keep the bug open until it has been back-ported to 10.5. Perhaps it should go all way back to 10.4, since DERBY-4028, which made it possible to expose this bug, was also back-ported to 10.4.

        Show
        Knut Anders Hatlen added a comment - Committed revision 805696. I will keep the bug open until it has been back-ported to 10.5. Perhaps it should go all way back to 10.4, since DERBY-4028 , which made it possible to expose this bug, was also back-ported to 10.4.
        Hide
        Knut Anders Hatlen added a comment -

        Merged fix to 10.4 (revision 806139) and 10.5 (revision 806138).

        Show
        Knut Anders Hatlen added a comment - Merged fix to 10.4 (revision 806139) and 10.5 (revision 806138).

          People

          • Assignee:
            Knut Anders Hatlen
            Reporter:
            Knut Anders Hatlen
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development