harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Cornwall (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-5611) [classlib][pack200] IcTuple parsing broken: IcTuple.C can equal IcTuple.C2?
Date Mon, 17 Mar 2008 19:40:24 GMT

    [ 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.


Mime
View raw message