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/26 23:33:25 UTC
[jira] Commented: (HARMONY-5654) [classlib][pack200] Init methods
cannot be synchronized
[ https://issues.apache.org/jira/browse/HARMONY-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582458#action_12582458 ]
Andrew Cornwall commented on HARMONY-5654:
------------------------------------------
This does look like an encoding issue to me. Using the attached pack200.pack.gz and unpacking, I find that parseFlags("method_flags"...) is returning 131104 (0x20020) for methodFlags[19][2], which corresponds to NewAttributeBands$LayoutElement.<init>(NewAttributeBands, NewAttributeBands$LayoutElement). In the original JAR (which I exported from my pack200 project in Eclipse), this method has an access_flags of 0x0.
Some useful code snippets for debugging:
>From ClassBands.parseMethodAttrBands:
private void parseMethodAttrBands(InputStream in) throws IOException, Pack200Exception {
methodFlags = parseFlags("method_flags", in, classMethodCount,
Codec.UNSIGNED5, options.hasMethodFlagsHi());
try {
if(((methodFlags[19][2]) & 0x20) == 0x20) {
System.out.println("Halt here: methodFlags[19][2] is "+ methodFlags[19][2]);
}
} catch (ArrayIndexOutOfBoundsException ex) {
// do nothing
}
...
>From Segment.buildClassFile:
// add methods
ClassFileEntry cfMethods[] = new ClassFileEntry[classBands.getClassMethodCount()[classNum]];
// fieldDescr and fieldFlags used to create this
for (i = 0; i < cfMethods.length; i++) {
String descriptorStr = classBands.getMethodDescr()[classNum][i];
int colon = descriptorStr.indexOf(':');
CPUTF8 name = cpBands.cpUTF8Value(descriptorStr.substring(0,colon), ClassConstantPool.DOMAIN_NORMALASCIIZ);
CPUTF8 descriptor = cpBands.cpUTF8Value(descriptorStr.substring(colon+1), ClassConstantPool.DOMAIN_SIGNATUREASCIIZ);
if((classNum == 19) && (i==2)) {
System.out.println("self halt");
}
cfMethods[i] = cp.add(new CPMethod(name, descriptor, classBands
.getMethodFlags()[classNum][i], classBands
.getMethodAttributes()[classNum][i]));
}
(Also incidentally, shouldn't the comment be:
// methodDescr and methodFlags used to create this
instead of fieldFlags? Looks like a cut & paste error from the code above.)
> [classlib][pack200] Init methods cannot be synchronized
> -------------------------------------------------------
>
> Key: HARMONY-5654
> URL: https://issues.apache.org/jira/browse/HARMONY-5654
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Environment: All pack200
> Reporter: Andrew Cornwall
> Attachments: pack200.pack.gz
>
>
> In the current code, it's possible for a CPMethod <init> to be emitted as synchronized. This will not pass Sun's verification. For instance, if you run pack200 on itself, NewAttributeBands$LayoutElement in the following will be emitted with a synchronized <init>.
> I've temporarily hacked this with the following code in CPMethod:
> public CPMethod(CPUTF8 name, CPUTF8 descriptor, long flags, List attributes) {
> // TODO Check that we only pass these on, or remap
> super(name, descriptor, 0x7FFF & flags, attributes);
> if(name.underlyingString().equals("<init>")) {
> // hack hack - init should never be synchronized
> SegmentUtils.debug("Hacking off synchronized on an init method");
> this.flags = (short)(this.flags & 0x7FDF);
> }
> }
> but I really need to look into it more deeply and find out why the 0x20 flag is being passed in. (This may end up being an encoding issue, but I need to look more first).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.