CDV ❯ clone() on shared array types might fail to resolve values before native cloning

• Type: Bug
• Status: Closed
• Priority: 1 Critical
• Resolution: Fixed
• Component/s: Byte Code Transform
• Labels:

• Assignee: teck
• Reporter: teck
• Created: April 02, 2009
• Votes: 0
• Watchers: 0
• Updated:

  May 20, 2009
• Resolved:

  April 06, 2009

Description

This only effects code compiled with 1.5 or greater I think. com.tc.object.bytecode.TransparencyCodeAdapter.handleJavaLangObjectMethodCall(int, String, String, String) is making a wrong assumption. The call to clone() is made directly to the array type. Example:

public static void main(String[] args) { String[] args2 = args.clone(); System.err.println(args2); }

If compiled with 1.4, the clone calls looks like this: mv.visitMethodInsn(INVOKEVIRTUAL, “java/lang/Object”, “clone”, “()Ljava/lang/Object;”);

If compiled with 1.5, the clone calls looks like this: mv.visitMethodInsn(INVOKEVIRTUAL, “[Ljava/lang/String;”, “clone”, “()Ljava/lang/Object;”);

Since the call isn’t direct to java.lang.Object we won’t insert our magic wrapping that makes sure the element values are resolved (and done within the resolve lock)

Comments

Tim Eck 2009-04-02

This is definitely broken – and now fixed in trunk. Need to merge to 3.0 when the branch is open

Kalai Kannaiyan 2009-05-19

Tim added test ArrayCloneTest.