You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Andrew Cornwall (JIRA)" <ji...@apache.org> on 2008/03/14 21:36:24 UTC
[jira] Created: (HARMONY-5611) [classlib][pack200] IcTuple parsing
broken: IcTuple.C can equal IcTuple.C2?
[classlib][pack200] IcTuple parsing broken: IcTuple.C can equal IcTuple.C2?
---------------------------------------------------------------------------
Key: HARMONY-5611
URL: https://issues.apache.org/jira/browse/HARMONY-5611
Project: Harmony
Issue Type: Bug
Components: Classlib
Environment: Pack200 head
Reporter: Andrew Cornwall
I've run into a case where IcTuple.C is equal to IcTuple.C2. In my case, I have an IcTuple.C of "com/ibm/micro/eventlog/LogDestination$1" and IcTuple.C2 of "com/ibm/micro/eventlog/LogDestination$1". This causes a failure later on, because the algorithm used to determine what class the inner class belongs to fails.
I've sent a (confidential) test case to Sian. This problem can be exposed by modifying the end of IcBands.unpack() as follows:
// Construct IC tuples
icAll = new IcTuple[icThisClass.length];
int index = 0;
for (int i = 0; i < icThisClass.length; i++) {
icAll[i] = new IcTuple();
icAll[i].C = icThisClass[i];
// TODO: remove debug code
if(icAll[i].C.matches(".*LogDestination.*")) {
System.out.println("self halt");
}
icAll[i].F = icFlags[i];
if((icFlags[i] & 1<<16) != 0) {
if(icOuterClass[index].equals(icAll[i].C)) {
throw new Error("Inner class equals outer class");
}
icAll[i].C2 = icOuterClass[index];
icAll[i].N = icName[index];
index++;
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5611) [classlib][pack200] IcTuple
parsing broken: IcTuple.C can equal IcTuple.C2?
Posted by "Andrew Cornwall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579921#action_12579921 ]
Andrew Cornwall commented on HARMONY-5611:
------------------------------------------
I keep getting the logic backwards on this :-(
If F is correct (implying the name is predicted):
C2 and N should not be transmitted
If F is incorrect (implying the name is specified explicitly):
C2 and N should both be transmitted
Unless I'm reading the spec wrong...
> [classlib][pack200] IcTuple parsing broken: IcTuple.C can equal IcTuple.C2?
> ---------------------------------------------------------------------------
>
> Key: HARMONY-5611
> URL: https://issues.apache.org/jira/browse/HARMONY-5611
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: Pack200 head
> Reporter: Andrew Cornwall
> Assignee: Sian January
> Fix For: 5.0M6
>
>
> I've run into a case where IcTuple.C is equal to IcTuple.C2. In my case, I have an IcTuple.C of "com/ibm/micro/eventlog/LogDestination$1" and IcTuple.C2 of "com/ibm/micro/eventlog/LogDestination$1". This causes a failure later on, because the algorithm used to determine what class the inner class belongs to fails.
> I've sent a (confidential) test case to Sian. This problem can be exposed by modifying the end of IcBands.unpack() as follows:
> // Construct IC tuples
> icAll = new IcTuple[icThisClass.length];
> int index = 0;
> for (int i = 0; i < icThisClass.length; i++) {
> icAll[i] = new IcTuple();
> icAll[i].C = icThisClass[i];
> // TODO: remove debug code
> if(icAll[i].C.matches(".*LogDestination.*")) {
> System.out.println("self halt");
> }
> icAll[i].F = icFlags[i];
> if((icFlags[i] & 1<<16) != 0) {
> if(icOuterClass[index].equals(icAll[i].C)) {
> throw new Error("Inner class equals outer class");
> }
> icAll[i].C2 = icOuterClass[index];
> icAll[i].N = icName[index];
> index++;
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (HARMONY-5611) [classlib][pack200] IcTuple parsing
broken: IcTuple.C can equal IcTuple.C2?
Posted by "Andrew Cornwall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Cornwall closed HARMONY-5611.
------------------------------------
I'm pretty sure you're right. Closing this issue.
> [classlib][pack200] IcTuple parsing broken: IcTuple.C can equal IcTuple.C2?
> ---------------------------------------------------------------------------
>
> Key: HARMONY-5611
> URL: https://issues.apache.org/jira/browse/HARMONY-5611
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: Pack200 head
> Reporter: Andrew Cornwall
> Assignee: Sian January
> Fix For: 5.0M6
>
>
> I've run into a case where IcTuple.C is equal to IcTuple.C2. In my case, I have an IcTuple.C of "com/ibm/micro/eventlog/LogDestination$1" and IcTuple.C2 of "com/ibm/micro/eventlog/LogDestination$1". This causes a failure later on, because the algorithm used to determine what class the inner class belongs to fails.
> I've sent a (confidential) test case to Sian. This problem can be exposed by modifying the end of IcBands.unpack() as follows:
> // Construct IC tuples
> icAll = new IcTuple[icThisClass.length];
> int index = 0;
> for (int i = 0; i < icThisClass.length; i++) {
> icAll[i] = new IcTuple();
> icAll[i].C = icThisClass[i];
> // TODO: remove debug code
> if(icAll[i].C.matches(".*LogDestination.*")) {
> System.out.println("self halt");
> }
> icAll[i].F = icFlags[i];
> if((icFlags[i] & 1<<16) != 0) {
> if(icOuterClass[index].equals(icAll[i].C)) {
> throw new Error("Inner class equals outer class");
> }
> icAll[i].C2 = icOuterClass[index];
> icAll[i].N = icName[index];
> index++;
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5611) [classlib][pack200] IcTuple
parsing broken: IcTuple.C can equal IcTuple.C2?
Posted by "Andrew Cornwall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579572#action_12579572 ]
Andrew Cornwall commented on HARMONY-5611:
------------------------------------------
Is it possible your changes altered the calculation of .F ? That would account for the problem I'm seeing.
> [classlib][pack200] IcTuple parsing broken: IcTuple.C can equal IcTuple.C2?
> ---------------------------------------------------------------------------
>
> Key: HARMONY-5611
> URL: https://issues.apache.org/jira/browse/HARMONY-5611
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: Pack200 head
> Reporter: Andrew Cornwall
> Assignee: Sian January
> Fix For: 5.0M6
>
>
> I've run into a case where IcTuple.C is equal to IcTuple.C2. In my case, I have an IcTuple.C of "com/ibm/micro/eventlog/LogDestination$1" and IcTuple.C2 of "com/ibm/micro/eventlog/LogDestination$1". This causes a failure later on, because the algorithm used to determine what class the inner class belongs to fails.
> I've sent a (confidential) test case to Sian. This problem can be exposed by modifying the end of IcBands.unpack() as follows:
> // Construct IC tuples
> icAll = new IcTuple[icThisClass.length];
> int index = 0;
> for (int i = 0; i < icThisClass.length; i++) {
> icAll[i] = new IcTuple();
> icAll[i].C = icThisClass[i];
> // TODO: remove debug code
> if(icAll[i].C.matches(".*LogDestination.*")) {
> System.out.println("self halt");
> }
> icAll[i].F = icFlags[i];
> if((icFlags[i] & 1<<16) != 0) {
> if(icOuterClass[index].equals(icAll[i].C)) {
> throw new Error("Inner class equals outer class");
> }
> icAll[i].C2 = icOuterClass[index];
> icAll[i].N = icName[index];
> index++;
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5611) [classlib][pack200] IcTuple
parsing broken: IcTuple.C can equal IcTuple.C2?
Posted by "Andrew Cornwall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579567#action_12579567 ]
Andrew Cornwall commented on HARMONY-5611:
------------------------------------------
This is close, but not exact. Now I'm seeing things like:
inner_class_info_index = #18 // "com/ibm/micro/eventlog/LogDestination$null"
outer_class_info_index = #16 // "com/ibm/micro/eventlog/LogDestination"
inner_name_index = #43 // ""
inner_class_access_flags = x08 // STATIC
when they should be:
inner_class_info_index = #18 // "com/ibm/micro/eventlog/LogDestination$1"
outer_class_info_index = #16 // "com/ibm/micro/eventlog/LogDestination"
inner_name_index = #0 // anonymous inner class
inner_class_access_flags = x08 // STATIC
This appears to be happening because the tuple's .F is 65544 (which means it should be predicted from C) but it's being assigned a C2 and a null N.
> [classlib][pack200] IcTuple parsing broken: IcTuple.C can equal IcTuple.C2?
> ---------------------------------------------------------------------------
>
> Key: HARMONY-5611
> URL: https://issues.apache.org/jira/browse/HARMONY-5611
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: Pack200 head
> Reporter: Andrew Cornwall
> Assignee: Sian January
> Fix For: 5.0M6
>
>
> I've run into a case where IcTuple.C is equal to IcTuple.C2. In my case, I have an IcTuple.C of "com/ibm/micro/eventlog/LogDestination$1" and IcTuple.C2 of "com/ibm/micro/eventlog/LogDestination$1". This causes a failure later on, because the algorithm used to determine what class the inner class belongs to fails.
> I've sent a (confidential) test case to Sian. This problem can be exposed by modifying the end of IcBands.unpack() as follows:
> // Construct IC tuples
> icAll = new IcTuple[icThisClass.length];
> int index = 0;
> for (int i = 0; i < icThisClass.length; i++) {
> icAll[i] = new IcTuple();
> icAll[i].C = icThisClass[i];
> // TODO: remove debug code
> if(icAll[i].C.matches(".*LogDestination.*")) {
> System.out.println("self halt");
> }
> icAll[i].F = icFlags[i];
> if((icFlags[i] & 1<<16) != 0) {
> if(icOuterClass[index].equals(icAll[i].C)) {
> throw new Error("Inner class equals outer class");
> }
> icAll[i].C2 = icOuterClass[index];
> icAll[i].N = icName[index];
> index++;
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5611) [classlib][pack200] IcTuple
parsing broken: IcTuple.C can equal IcTuple.C2?
Posted by "Sian January (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579923#action_12579923 ]
Sian January commented on HARMONY-5611:
---------------------------------------
Isn't the class name always C and it's C2 and N that may or may not be predicted?
So you would use C for inner_class_info_index, C2 for outer_class_info_index and N for inner_name_index (but give it an index of 0 because it's null)
Does that make any sense?
> [classlib][pack200] IcTuple parsing broken: IcTuple.C can equal IcTuple.C2?
> ---------------------------------------------------------------------------
>
> Key: HARMONY-5611
> URL: https://issues.apache.org/jira/browse/HARMONY-5611
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: Pack200 head
> Reporter: Andrew Cornwall
> Assignee: Sian January
> Fix For: 5.0M6
>
>
> I've run into a case where IcTuple.C is equal to IcTuple.C2. In my case, I have an IcTuple.C of "com/ibm/micro/eventlog/LogDestination$1" and IcTuple.C2 of "com/ibm/micro/eventlog/LogDestination$1". This causes a failure later on, because the algorithm used to determine what class the inner class belongs to fails.
> I've sent a (confidential) test case to Sian. This problem can be exposed by modifying the end of IcBands.unpack() as follows:
> // Construct IC tuples
> icAll = new IcTuple[icThisClass.length];
> int index = 0;
> for (int i = 0; i < icThisClass.length; i++) {
> icAll[i] = new IcTuple();
> icAll[i].C = icThisClass[i];
> // TODO: remove debug code
> if(icAll[i].C.matches(".*LogDestination.*")) {
> System.out.println("self halt");
> }
> icAll[i].F = icFlags[i];
> if((icFlags[i] & 1<<16) != 0) {
> if(icOuterClass[index].equals(icAll[i].C)) {
> throw new Error("Inner class equals outer class");
> }
> icAll[i].C2 = icOuterClass[index];
> icAll[i].N = icName[index];
> index++;
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5611) [classlib][pack200] IcTuple
parsing broken: IcTuple.C can equal IcTuple.C2?
Posted by "Sian January (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579785#action_12579785 ]
Sian January commented on HARMONY-5611:
---------------------------------------
If I put a breakpoint on line 94 of IcBands (getIcTuples) and inspect icAll it looks like this for the first entry:
- C is com/ibm/micro/eventlog/LogDestination$1
- C2 is com/ibm/micro/eventlog/LogDestination
- N is null (which is allowed - presumably this means it's anonymous)
- F is 65544
The calculation for F hasn't changed, but these values look ok to me anyway... Are they being changed somehow later on?
> [classlib][pack200] IcTuple parsing broken: IcTuple.C can equal IcTuple.C2?
> ---------------------------------------------------------------------------
>
> Key: HARMONY-5611
> URL: https://issues.apache.org/jira/browse/HARMONY-5611
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: Pack200 head
> Reporter: Andrew Cornwall
> Assignee: Sian January
> Fix For: 5.0M6
>
>
> I've run into a case where IcTuple.C is equal to IcTuple.C2. In my case, I have an IcTuple.C of "com/ibm/micro/eventlog/LogDestination$1" and IcTuple.C2 of "com/ibm/micro/eventlog/LogDestination$1". This causes a failure later on, because the algorithm used to determine what class the inner class belongs to fails.
> I've sent a (confidential) test case to Sian. This problem can be exposed by modifying the end of IcBands.unpack() as follows:
> // Construct IC tuples
> icAll = new IcTuple[icThisClass.length];
> int index = 0;
> for (int i = 0; i < icThisClass.length; i++) {
> icAll[i] = new IcTuple();
> icAll[i].C = icThisClass[i];
> // TODO: remove debug code
> if(icAll[i].C.matches(".*LogDestination.*")) {
> System.out.println("self halt");
> }
> icAll[i].F = icFlags[i];
> if((icFlags[i] & 1<<16) != 0) {
> if(icOuterClass[index].equals(icAll[i].C)) {
> throw new Error("Inner class equals outer class");
> }
> icAll[i].C2 = icOuterClass[index];
> icAll[i].N = icName[index];
> index++;
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5611) [classlib][pack200] IcTuple
parsing broken: IcTuple.C can equal IcTuple.C2?
Posted by "Andrew Cornwall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579920#action_12579920 ]
Andrew Cornwall commented on HARMONY-5611:
------------------------------------------
Those values are what I see as well - but they don't seem right. If F is 65544, then (since bit position 16 is set) the class name is not predicted, but instead uses what's stored in C2 and N to generate the class name. I can't see a way to do this without having N assigned a value.
If F is correct, there should be no value transmitted for either C2 or for N.
So either:
F is correct - in which case C2 is correct and N needs to be transmitted as well
F is incorrect - in which case both C2 and N should not be transmitted
> [classlib][pack200] IcTuple parsing broken: IcTuple.C can equal IcTuple.C2?
> ---------------------------------------------------------------------------
>
> Key: HARMONY-5611
> URL: https://issues.apache.org/jira/browse/HARMONY-5611
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: Pack200 head
> Reporter: Andrew Cornwall
> Assignee: Sian January
> Fix For: 5.0M6
>
>
> I've run into a case where IcTuple.C is equal to IcTuple.C2. In my case, I have an IcTuple.C of "com/ibm/micro/eventlog/LogDestination$1" and IcTuple.C2 of "com/ibm/micro/eventlog/LogDestination$1". This causes a failure later on, because the algorithm used to determine what class the inner class belongs to fails.
> I've sent a (confidential) test case to Sian. This problem can be exposed by modifying the end of IcBands.unpack() as follows:
> // Construct IC tuples
> icAll = new IcTuple[icThisClass.length];
> int index = 0;
> for (int i = 0; i < icThisClass.length; i++) {
> icAll[i] = new IcTuple();
> icAll[i].C = icThisClass[i];
> // TODO: remove debug code
> if(icAll[i].C.matches(".*LogDestination.*")) {
> System.out.println("self halt");
> }
> icAll[i].F = icFlags[i];
> if((icFlags[i] & 1<<16) != 0) {
> if(icOuterClass[index].equals(icAll[i].C)) {
> throw new Error("Inner class equals outer class");
> }
> icAll[i].C2 = icOuterClass[index];
> icAll[i].N = icName[index];
> index++;
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HARMONY-5611) [classlib][pack200] IcTuple parsing
broken: IcTuple.C can equal IcTuple.C2?
Posted by "Sian January (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sian January reassigned HARMONY-5611:
-------------------------------------
Assignee: Sian January
> [classlib][pack200] IcTuple parsing broken: IcTuple.C can equal IcTuple.C2?
> ---------------------------------------------------------------------------
>
> Key: HARMONY-5611
> URL: https://issues.apache.org/jira/browse/HARMONY-5611
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: Pack200 head
> Reporter: Andrew Cornwall
> Assignee: Sian January
>
> I've run into a case where IcTuple.C is equal to IcTuple.C2. In my case, I have an IcTuple.C of "com/ibm/micro/eventlog/LogDestination$1" and IcTuple.C2 of "com/ibm/micro/eventlog/LogDestination$1". This causes a failure later on, because the algorithm used to determine what class the inner class belongs to fails.
> I've sent a (confidential) test case to Sian. This problem can be exposed by modifying the end of IcBands.unpack() as follows:
> // Construct IC tuples
> icAll = new IcTuple[icThisClass.length];
> int index = 0;
> for (int i = 0; i < icThisClass.length; i++) {
> icAll[i] = new IcTuple();
> icAll[i].C = icThisClass[i];
> // TODO: remove debug code
> if(icAll[i].C.matches(".*LogDestination.*")) {
> System.out.println("self halt");
> }
> icAll[i].F = icFlags[i];
> if((icFlags[i] & 1<<16) != 0) {
> if(icOuterClass[index].equals(icAll[i].C)) {
> throw new Error("Inner class equals outer class");
> }
> icAll[i].C2 = icOuterClass[index];
> icAll[i].N = icName[index];
> index++;
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5611) [classlib][pack200] IcTuple
parsing broken: IcTuple.C can equal IcTuple.C2?
Posted by "Andrew Cornwall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579922#action_12579922 ]
Andrew Cornwall commented on HARMONY-5611:
------------------------------------------
And I *am* reading the spec wrong:
If a tuple has an entry in the ic_outer_class and ic_name bands, these specify its outer class and simple name. (They are represented respectively as a possibly null cp_Class reference and a possibly null cp_Utf8 reference.) Otherwise, the tuple's outer class and name are said to be predicted. In this case, they must be correctly predictable from the name of the nested class itself, by parsing its spelling.
So I can't use ic_flags to determine whether or not the class name is predicted.
> [classlib][pack200] IcTuple parsing broken: IcTuple.C can equal IcTuple.C2?
> ---------------------------------------------------------------------------
>
> Key: HARMONY-5611
> URL: https://issues.apache.org/jira/browse/HARMONY-5611
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: Pack200 head
> Reporter: Andrew Cornwall
> Assignee: Sian January
> Fix For: 5.0M6
>
>
> I've run into a case where IcTuple.C is equal to IcTuple.C2. In my case, I have an IcTuple.C of "com/ibm/micro/eventlog/LogDestination$1" and IcTuple.C2 of "com/ibm/micro/eventlog/LogDestination$1". This causes a failure later on, because the algorithm used to determine what class the inner class belongs to fails.
> I've sent a (confidential) test case to Sian. This problem can be exposed by modifying the end of IcBands.unpack() as follows:
> // Construct IC tuples
> icAll = new IcTuple[icThisClass.length];
> int index = 0;
> for (int i = 0; i < icThisClass.length; i++) {
> icAll[i] = new IcTuple();
> icAll[i].C = icThisClass[i];
> // TODO: remove debug code
> if(icAll[i].C.matches(".*LogDestination.*")) {
> System.out.println("self halt");
> }
> icAll[i].F = icFlags[i];
> if((icFlags[i] & 1<<16) != 0) {
> if(icOuterClass[index].equals(icAll[i].C)) {
> throw new Error("Inner class equals outer class");
> }
> icAll[i].C2 = icOuterClass[index];
> icAll[i].N = icName[index];
> index++;
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HARMONY-5611) [classlib][pack200] IcTuple parsing
broken: IcTuple.C can equal IcTuple.C2?
Posted by "Sian January (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sian January resolved HARMONY-5611.
-----------------------------------
Resolution: Fixed
Fix Version/s: 5.0M6
Fixed at r637969. Andrew - please confirm that this fully resolves your issue.
> [classlib][pack200] IcTuple parsing broken: IcTuple.C can equal IcTuple.C2?
> ---------------------------------------------------------------------------
>
> Key: HARMONY-5611
> URL: https://issues.apache.org/jira/browse/HARMONY-5611
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: Pack200 head
> Reporter: Andrew Cornwall
> Assignee: Sian January
> Fix For: 5.0M6
>
>
> I've run into a case where IcTuple.C is equal to IcTuple.C2. In my case, I have an IcTuple.C of "com/ibm/micro/eventlog/LogDestination$1" and IcTuple.C2 of "com/ibm/micro/eventlog/LogDestination$1". This causes a failure later on, because the algorithm used to determine what class the inner class belongs to fails.
> I've sent a (confidential) test case to Sian. This problem can be exposed by modifying the end of IcBands.unpack() as follows:
> // Construct IC tuples
> icAll = new IcTuple[icThisClass.length];
> int index = 0;
> for (int i = 0; i < icThisClass.length; i++) {
> icAll[i] = new IcTuple();
> icAll[i].C = icThisClass[i];
> // TODO: remove debug code
> if(icAll[i].C.matches(".*LogDestination.*")) {
> System.out.println("self halt");
> }
> icAll[i].F = icFlags[i];
> if((icFlags[i] & 1<<16) != 0) {
> if(icOuterClass[index].equals(icAll[i].C)) {
> throw new Error("Inner class equals outer class");
> }
> icAll[i].C2 = icOuterClass[index];
> icAll[i].N = icName[index];
> index++;
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-5611) [classlib][pack200] IcTuple
parsing broken: IcTuple.C can equal IcTuple.C2?
Posted by "Andrew Cornwall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579571#action_12579571 ]
Andrew Cornwall commented on HARMONY-5611:
------------------------------------------
...(means it should NOT be predicted from C) but it's being assigned a C2 and a null N.
> [classlib][pack200] IcTuple parsing broken: IcTuple.C can equal IcTuple.C2?
> ---------------------------------------------------------------------------
>
> Key: HARMONY-5611
> URL: https://issues.apache.org/jira/browse/HARMONY-5611
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: Pack200 head
> Reporter: Andrew Cornwall
> Assignee: Sian January
> Fix For: 5.0M6
>
>
> I've run into a case where IcTuple.C is equal to IcTuple.C2. In my case, I have an IcTuple.C of "com/ibm/micro/eventlog/LogDestination$1" and IcTuple.C2 of "com/ibm/micro/eventlog/LogDestination$1". This causes a failure later on, because the algorithm used to determine what class the inner class belongs to fails.
> I've sent a (confidential) test case to Sian. This problem can be exposed by modifying the end of IcBands.unpack() as follows:
> // Construct IC tuples
> icAll = new IcTuple[icThisClass.length];
> int index = 0;
> for (int i = 0; i < icThisClass.length; i++) {
> icAll[i] = new IcTuple();
> icAll[i].C = icThisClass[i];
> // TODO: remove debug code
> if(icAll[i].C.matches(".*LogDestination.*")) {
> System.out.println("self halt");
> }
> icAll[i].F = icFlags[i];
> if((icFlags[i] & 1<<16) != 0) {
> if(icOuterClass[index].equals(icAll[i].C)) {
> throw new Error("Inner class equals outer class");
> }
> icAll[i].C2 = icOuterClass[index];
> icAll[i].N = icName[index];
> index++;
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.