You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Jonathan Feinberg (JIRA)" <ji...@apache.org> on 2007/06/12 20:22:25 UTC
[jira] Created: (OPENJPA-258) MetaDataInheritanceComparator is not
transitive; C > B > A > C leads to out-of-memory crash in PCEnhancer
MetaDataInheritanceComparator is not transitive; C > B > A > C leads to out-of-memory crash in PCEnhancer
---------------------------------------------------------------------------------------------------------
Key: OPENJPA-258
URL: https://issues.apache.org/jira/browse/OPENJPA-258
Project: OpenJPA
Issue Type: Bug
Components: jpa
Affects Versions: 1.0.0
Environment: Sun JDK 5, Sun JDK 6
Reporter: Jonathan Feinberg
Priority: Blocker
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-258) MetaDataInheritanceComparator is not
transitive; C > B > A > C leads to out-of-memory crash in PCEnhancer
Posted by "Albert Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Albert Lee updated OPENJPA-258:
-------------------------------
Fix Version/s: (was: 1.0.1)
1.0.2
Defer to next release.
> MetaDataInheritanceComparator is not transitive; C > B > A > C leads to out-of-memory crash in PCEnhancer
> ---------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-258
> URL: https://issues.apache.org/jira/browse/OPENJPA-258
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Affects Versions: 0.9.6
> Environment: Sun JDK 5, Sun JDK 6
> Reporter: Jonathan Feinberg
> Priority: Blocker
> Fix For: 1.0.2
>
> Attachments: jpa-comparator-bug.zip
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (OPENJPA-258)
MetaDataInheritanceComparator is not transitive; C > B > A > C leads to
out-of-memory crash in PCEnhancer
Posted by "Jonathan Feinberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503952 ]
Jonathan Feinberg edited comment on OPENJPA-258 at 6/12/07 11:23 AM:
---------------------------------------------------------------------
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.
was:
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.
> MetaDataInheritanceComparator is not transitive; C > B > A > C leads to out-of-memory crash in PCEnhancer
> ---------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-258
> URL: https://issues.apache.org/jira/browse/OPENJPA-258
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Affects Versions: 1.0.0
> Environment: Sun JDK 5, Sun JDK 6
> Reporter: Jonathan Feinberg
> Priority: Blocker
> Attachments: jpa-comparator-bug.zip
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-258) MetaDataInheritanceComparator is not
transitive; C > B > A > C leads to out-of-memory crash in PCEnhancer
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Linskey updated OPENJPA-258:
------------------------------------
Fix Version/s: 1.1.0
> MetaDataInheritanceComparator is not transitive; C > B > A > C leads to out-of-memory crash in PCEnhancer
> ---------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-258
> URL: https://issues.apache.org/jira/browse/OPENJPA-258
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Affects Versions: 0.9.6
> Environment: Sun JDK 5, Sun JDK 6
> Reporter: Jonathan Feinberg
> Priority: Blocker
> Fix For: 1.0.2, 1.1.0
>
> Attachments: jpa-comparator-bug.zip
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-258) MetaDataInheritanceComparator is not
transitive; C > B > A > C leads to out-of-memory crash in PCEnhancer
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Linskey resolved OPENJPA-258.
-------------------------------------
Resolution: Fixed
> MetaDataInheritanceComparator is not transitive; C > B > A > C leads to out-of-memory crash in PCEnhancer
> ---------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-258
> URL: https://issues.apache.org/jira/browse/OPENJPA-258
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Affects Versions: 0.9.6
> Environment: Sun JDK 5, Sun JDK 6
> Reporter: Jonathan Feinberg
> Priority: Blocker
> Fix For: 1.0.2
>
> Attachments: jpa-comparator-bug.zip
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-258) MetaDataInheritanceComparator is not
transitive; C > B > A > C leads to out-of-memory crash in PCEnhancer
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Russell updated OPENJPA-258:
----------------------------------
Fix Version/s: 1.0.0
Affects Version/s: (was: 1.0.0)
0.9.6
> MetaDataInheritanceComparator is not transitive; C > B > A > C leads to out-of-memory crash in PCEnhancer
> ---------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-258
> URL: https://issues.apache.org/jira/browse/OPENJPA-258
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Affects Versions: 0.9.6
> Environment: Sun JDK 5, Sun JDK 6
> Reporter: Jonathan Feinberg
> Priority: Blocker
> Fix For: 1.0.0
>
> Attachments: jpa-comparator-bug.zip
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-258) MetaDataInheritanceComparator is not
transitive; C > B > A > C leads to out-of-memory crash in PCEnhancer
Posted by "Jonathan Feinberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Feinberg updated OPENJPA-258:
--------------------------------------
Attachment: jpa-comparator-bug.zip
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.
> MetaDataInheritanceComparator is not transitive; C > B > A > C leads to out-of-memory crash in PCEnhancer
> ---------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-258
> URL: https://issues.apache.org/jira/browse/OPENJPA-258
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Affects Versions: 1.0.0
> Environment: Sun JDK 5, Sun JDK 6
> Reporter: Jonathan Feinberg
> Priority: Blocker
> Attachments: jpa-comparator-bug.zip
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-258) MetaDataInheritanceComparator is not
transitive; C > B > A > C leads to out-of-memory crash in PCEnhancer
Posted by "Marc Prud'hommeaux (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marc Prud'hommeaux updated OPENJPA-258:
---------------------------------------
Fix Version/s: (was: 1.0.0)
1.0.1
Bumping to release 1.0.1 since 1.0.0 is being released.
> MetaDataInheritanceComparator is not transitive; C > B > A > C leads to out-of-memory crash in PCEnhancer
> ---------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-258
> URL: https://issues.apache.org/jira/browse/OPENJPA-258
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Affects Versions: 0.9.6
> Environment: Sun JDK 5, Sun JDK 6
> Reporter: Jonathan Feinberg
> Priority: Blocker
> Fix For: 1.0.1
>
> Attachments: jpa-comparator-bug.zip
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-258) MetaDataInheritanceComparator is not
transitive; C > B > A > C leads to out-of-memory crash in PCEnhancer
Posted by "Jonathan Feinberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Feinberg updated OPENJPA-258:
--------------------------------------
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.
was:
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.
> MetaDataInheritanceComparator is not transitive; C > B > A > C leads to out-of-memory crash in PCEnhancer
> ---------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-258
> URL: https://issues.apache.org/jira/browse/OPENJPA-258
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
> Affects Versions: 1.0.0
> Environment: Sun JDK 5, Sun JDK 6
> Reporter: Jonathan Feinberg
> Priority: Blocker
> Attachments: jpa-comparator-bug.zip
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.