OpenJPA
  1. OpenJPA
  2. OPENJPA-258

MetaDataInheritanceComparator is not transitive; C > B > A > C leads to out-of-memory crash in PCEnhancer

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 0.9.6
    • Fix Version/s: 1.0.2, 1.1.0
    • Component/s: jpa
    • Labels:
      None
    • Environment:
      Sun JDK 5, Sun JDK 6

      Description

      Comparisons done by MetaDataInheritanceComparator are not transitive. It is possible to have classes A, B, and C such that the comparator simultaneously reports that A > B, B > C, and C > A. Under certain unlucky conditions, this causes the SortedTree holding the metadata resolution buffer to become confused during Red-Black fix, such that it can retrieve a certain element, but not delete it. The "processed" list then grows until heap is exhausted.

      In the enclosed sample project,

      A < B by name
      B < C by assignable primary key field
      C < A by "levels" from base class (Object)

      If you import the enclosed eclipse project into an AspectJ-enabled eclipse, and refer the AspectJ compiler to an OpenJPA jar file, you'll get the following output:

      bug.B > bug.A
      bug.C > bug.B
      bug.A > bug.C
      Cycle detected:
      bug.A > bug.C > bug.B > bug.A

      The project will work outside of AspectJ, and will exhibit the out of memory condition described above.

      I acknowledge that the enclosed persistence.xml file is not kosher, in that it doesn't list all classes to be instrumented. My own project, affected by this bug, has a correct persistence.xml file. I had to work hard to contrive a simple example, as the order in which classes are buffered affects the appearance of the bug.

      There is no work-around that I know of. I don't believe that the comparator's semantics are well-defined.

      1. jpa-comparator-bug.zip
        5 kB
        Jonathan Feinberg

        Activity

        Jonathan Feinberg created issue -
        Hide
        Jonathan Feinberg added a comment - - edited

        Attached: An eclipse/AJDT project. When built and run with AspectJ, will instrument the defective comparator and fail fast on detection of cycle. Without AJDT, will run out of memory and die.

        Show
        Jonathan Feinberg added a comment - - edited Attached: An eclipse/AJDT project. When built and run with AspectJ, will instrument the defective comparator and fail fast on detection of cycle. Without AJDT, will run out of memory and die.
        Jonathan Feinberg made changes -
        Field Original Value New Value
        Attachment jpa-comparator-bug.zip [ 12359534 ]
        Jonathan Feinberg made changes -
        Description Comparisons done by MetaDataInheritanceComparator are not transitive. It is possible to have classes A, B, and C such that the comparator simultaneously reports that A > B, B > C, and C > A. Under certain unlucky conditions, this causes the SortedTree holding the metadata resolution buffer to become confused during Red-Black fix, such that it can retrieve a certain element, but not delete it. The "processed" list then grows until heap is exhausted.

        In the enclosed sample project,

        A < B by name
        B < C by assignable promary key field
        C < A by "levels" from base class (Object)

        If you import the enclosed eclipse project into an AspectJ-enabled eclipse, and refer the AspectJ compiler to an OpenJPA jar file, you'll get the following output:

          bug.B > bug.A
          bug.C > bug.B
          bug.A > bug.C
          Cycle detected:
          bug.A > bug.C > bug.B > bug.A

        The project will work outside of AspectJ, and will exhibit the out of memory condition described above.

        I acknowledge that the enclosed persistence.xml file is not kosher, in that it doesn't list all classes to be instrumented. My own project, affected by this bug, has a correct persistence.xml file. I had to work hard to contrive a simple example, as the order in which classes are buffered affects the appearance of the bug.

        There is no work-around that I know of. I don't believe that the comparator's semantics are well-defined.
        Comparisons done by MetaDataInheritanceComparator are not transitive. It is possible to have classes A, B, and C such that the comparator simultaneously reports that A > B, B > C, and C > A. Under certain unlucky conditions, this causes the SortedTree holding the metadata resolution buffer to become confused during Red-Black fix, such that it can retrieve a certain element, but not delete it. The "processed" list then grows until heap is exhausted.

        In the enclosed sample project,

        A < B by name
        B < C by assignable primary key field
        C < A by "levels" from base class (Object)

        If you import the enclosed eclipse project into an AspectJ-enabled eclipse, and refer the AspectJ compiler to an OpenJPA jar file, you'll get the following output:

          bug.B > bug.A
          bug.C > bug.B
          bug.A > bug.C
          Cycle detected:
          bug.A > bug.C > bug.B > bug.A

        The project will work outside of AspectJ, and will exhibit the out of memory condition described above.

        I acknowledge that the enclosed persistence.xml file is not kosher, in that it doesn't list all classes to be instrumented. My own project, affected by this bug, has a correct persistence.xml file. I had to work hard to contrive a simple example, as the order in which classes are buffered affects the appearance of the bug.

        There is no work-around that I know of. I don't believe that the comparator's semantics are well-defined.
        Craig L Russell made changes -
        Affects Version/s 0.9.6 [ 12312342 ]
        Affects Version/s 1.0.0 [ 12312341 ]
        Fix Version/s 1.0.0 [ 12312341 ]
        Hide
        Marc Prud'hommeaux added a comment -

        Bumping to release 1.0.1 since 1.0.0 is being released.

        Show
        Marc Prud'hommeaux added a comment - Bumping to release 1.0.1 since 1.0.0 is being released.
        Marc Prud'hommeaux made changes -
        Fix Version/s 1.0.1 [ 12312687 ]
        Fix Version/s 1.0.0 [ 12312341 ]
        Hide
        Albert Lee added a comment -

        Defer to next release.

        Show
        Albert Lee added a comment - Defer to next release.
        Albert Lee made changes -
        Fix Version/s 1.0.2 [ 12312846 ]
        Fix Version/s 1.0.1 [ 12312687 ]
        Patrick Linskey made changes -
        Resolution Fixed [ 1 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Patrick Linskey made changes -
        Fix Version/s 1.1.0 [ 12312344 ]
        Donald Woods made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        232d 13h 43m 1 Patrick Linskey 31/Jan/08 08:04
        Resolved Resolved Closed Closed
        768d 10h 27m 1 Donald Woods 09/Mar/10 18:32

          People

          • Assignee:
            Unassigned
            Reporter:
            Jonathan Feinberg
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development