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/17 20:40:24 UTC

[jira] Commented: (HARMONY-5611) [classlib][pack200] IcTuple parsing broken: IcTuple.C can equal IcTuple.C2?

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