Uploaded image for project: 'Lucene - Core'
  1. Lucene - Core
  2. LUCENE-5436

RefrenceManager#accquire can result in infinite loop if manager resource is abused outside of the manager

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 4.6.1, 4.7, 6.0
    • Fix Version/s: 4.7, 6.0
    • Component/s: core/search
    • Labels:
      None
    • Lucene Fields:
      New, Patch Available

      Description

      I think I found a bug that can cause the ReferenceManager to stick in an infinite loop if the managed reference is decremented outside of the manager without a corresponding increment. I think this is pretty bad since the debugging of this is a mess and we should rather throw ISE instead.

      1. LUCENE-5436.patch
        6 kB
        Simon Willnauer
      2. LUCENE-5436.patch
        5 kB
        Simon Willnauer
      3. LUCENE-5436.patch
        5 kB
        Simon Willnauer

        Activity

        Hide
        simonw Simon Willnauer added a comment -

        committed to 4x and trunk

        Show
        simonw Simon Willnauer added a comment - committed to 4x and trunk
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1565430 from Simon Willnauer in branch 'dev/branches/branch_4x'
        [ https://svn.apache.org/r1565430 ]

        LUCENE-5436: RefrenceManager#accquire can result in infinite loop if manager resource is abused outside of the manager

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1565430 from Simon Willnauer in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1565430 ] LUCENE-5436 : RefrenceManager#accquire can result in infinite loop if manager resource is abused outside of the manager
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 1565429 from Simon Willnauer in branch 'dev/trunk'
        [ https://svn.apache.org/r1565429 ]

        LUCENE-5436: RefrenceManager#accquire can result in infinite loop if manager resource is abused outside of the manager

        Show
        jira-bot ASF subversion and git services added a comment - Commit 1565429 from Simon Willnauer in branch 'dev/trunk' [ https://svn.apache.org/r1565429 ] LUCENE-5436 : RefrenceManager#accquire can result in infinite loop if manager resource is abused outside of the manager
        Hide
        simonw Simon Willnauer added a comment -

        here is a patch with a changes entry... I will commit shortly

        Show
        simonw Simon Willnauer added a comment - here is a patch with a changes entry... I will commit shortly
        Hide
        mikemccand Michael McCandless added a comment -

        +1, thanks Simon.

        Show
        mikemccand Michael McCandless added a comment - +1, thanks Simon.
        Hide
        simonw Simon Willnauer added a comment -

        here is a new patch using getRefCount...

        Show
        simonw Simon Willnauer added a comment - here is a new patch using getRefCount...
        Hide
        simonw Simon Willnauer added a comment -

        Hmm, sneaky. So we are adding best-effort catching of this mis-use?

        yeah this is nothing else than preventing the manager from going into an infinite loop.

        Instead of isClosed can we add protected getRefCount? That's just more consistent with the current abstract methods we already have?

        yeah I think that is a better name.

        Show
        simonw Simon Willnauer added a comment - Hmm, sneaky. So we are adding best-effort catching of this mis-use? yeah this is nothing else than preventing the manager from going into an infinite loop. Instead of isClosed can we add protected getRefCount? That's just more consistent with the current abstract methods we already have? yeah I think that is a better name.
        Hide
        mikemccand Michael McCandless added a comment -

        Hmm, sneaky. So we are adding best-effort catching of this mis-use?

        Instead of isClosed can we add protected getRefCount? That's just more consistent with the current abstract methods we already have?

        There's a small typo in the exception message (then -> the).

        Show
        mikemccand Michael McCandless added a comment - Hmm, sneaky. So we are adding best-effort catching of this mis-use? Instead of isClosed can we add protected getRefCount? That's just more consistent with the current abstract methods we already have? There's a small typo in the exception message (then -> the).
        Hide
        simonw Simon Willnauer added a comment -

        here is a patch and a test that shows the problem

        Show
        simonw Simon Willnauer added a comment - here is a patch and a test that shows the problem

          People

          • Assignee:
            simonw Simon Willnauer
            Reporter:
            simonw Simon Willnauer
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development