United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4750641 REGRESSION: Array.clone() broken in 1.4.1-b21
JDK-4750641 : REGRESSION: Array.clone() broken in 1.4.1-b21

Details
Type:
Bug
Submit Date:
2002-09-20
Status:
Closed
Updated Date:
2012-10-08
Project Name:
JDK
Resolved Date:
2002-09-25
Component:
hotspot
OS:
solaris_8,linux
Sub-Component:
runtime
CPU:
x86,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.1
Fixed Versions:
1.2.2_014 (014)

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:

Sub Tasks

Description
Name: gm110360			Date: 09/19/2002


FULL PRODUCT VERSION :
java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)


FULL OPERATING SYSTEM VERSION :
glibc-2.2.4-19.3
Linux quaffle 2.4.9-31smp #1 SMP Tue Feb 26 06:55:00 EST 2002 i686 unknown
/etc/redhat-release

A DESCRIPTION OF THE PROBLEM :
There was a regression between 1.4.1 release candidate (b19) and final version (b21) in accepting code
compiled by the jikes compiler.  Jikes 1.16 emits <array>.clone() rather than Object.clone() in the
bytecode, in accordance with JLS 13.1 (javac still does not do this, but that is a subject for a different
bug report).

With earlier VMs, the sample program below worked, but now it causes a VerifyError.


This bug may require specification clarification, in both the JLS and the JVMS.  See also my longer
description of this issue at http://groups.yahoo.com/group/java-spec-report/message/764.



REGRESSION.  Last worked in version 1.4.1

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Compile the program below with jikes 1.16 or greater (jikes is obtainable from
http://www-124.ibm.com/developerworks/project/showfiles.php?group_id=10). Compilation with javac does not
show this bug - you need jikes (or else manually assembling a .class file to call invokevirtual
String[].clone()).

$ jikes Foo.java
$

2. Execute with the b19 or earlier builds
$ /opt/java/bin/java -version
java version "1.3.1_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_04-b02)
Java HotSpot(TM) Client VM (build 1.3.1_04-b02, mixed mode)
$ /opt/java/bin/java Foo
[Ljava.lang.String;@1fcc69
$

3. Try again with 1.4.1 final candidate.
$ java version
java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)
$ java Foo
Exception in thread "main" java.lang.IllegalAccessError: tried to access method
java.lang.Object.clone()Ljava/lang/Object; from class Foo
        at Foo.main(Foo.java:3)
$


EXPECTED VERSUS ACTUAL BEHAVIOR :
The program should always execute. However, the 1.4.1 final regression causes a VerifyError:


ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "main" java.lang.IllegalAccessError: tried to access method
java.lang.Object.clone()Ljava/lang/Object; from class Foo
        at Foo.main(Foo.java:3)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
class Foo {
  public static void main(String[] args) {
    System.out.println(args.clone());
  }
}


---------- END SOURCE ----------

CUSTOMER WORKAROUND :
Jikes 1.16 cannot be used if the targetted VM is java 1.4.1-b21. A bug was raised against jikes
(http://www-124.ibm.com/developerworks/bugs/?func=detailbug&bug_id=3290&group_id=10), so future versions may
emit Object.clone() the way javac does currently, but I think this violates JLS 13.1.

Meanwhile, the user can revert to an older VM, or can do the following to avoid the VerifyError when
compiling with jikes 1.16:
class Foo {
  public static void main(String[] args) {
    Cloneable o = args;
    try {
      o.clone();
    } catch (CloneNotSupportedException e) {
      assert false : "Impossible - array clones always succeed";
    }
  }
}

Release Regression From : 1.4.1
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Review ID: 164758) 
======================================================================

                                    

Comments
SUGGESTED FIX


(Suggestion by Jeff Nisewanger):

	In order to account for this, we need to modify
LinkResolver::check_method_accessability(). If the symbolic
class ("resolved_klass") is an array class and the method
name is "clone" and the declaring class ("sel_klass") is
java.lang.Object and the access flags are set to "protected"
then make the 2nd parameter in the call to verify_field_access()
be the same as the 3rd (or the 1st, either works). We might
be able to reduce this to just checking for the symbolic
class being an array class and the method name being "clone".
In other words, for the special case of checking access to the
clone() method on an array we will make the new JVMS 5.4.4
test be a no-op taking us back to the behavior of 1.4.0 etc.
A slight variation that would be more self-documenting
would be to pass an access flags of "public" instead of
changing the 2nd parameter since the real bug here is that
we need to notice that this is a call to clone() on an
array and the access modifier for clone() on an array is
public instead of the protected modifier an array otherwise
inherits from java.lang.Object.

I've implemented the variation (modify the access flags used in
the check for this special case).

###@###.### 2002-09-23

Files:
update: src/share/vm/interpreter/linkResolver.cpp
update: src/share/vm/memory/vmSymbols.hpp


###@###.### 2002-09-25
                                     
2002-09-23
EVALUATION


VM wasn't honoring JVMS 2.15's special case for arrays:

  Arrays are objects, are dynamically created, and may be
  assigned to variables of type Object (??2.4.7). All methods
  on arrays are inherited from class Object except the clone
  method, which arrays override. All arrays implement the
  interfaces Cloneable and java.io.Serializable.

###@###.### 2002-09-23
                                     
2002-09-23
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
1.2.2_014
1.2.2_14
1.3.1_06
1.4.0_03
1.4.1_01
mantis

FIXED IN:
1.2.2_014
1.2.2_14
1.3.1_06
1.4.0_03
1.4.1_01
mantis

INTEGRATED IN:
1.2.2_014
1.2.2_14
1.3.1_06
1.4.0_03
1.4.1_01
mantis


                                     
2004-06-14



Hardware and Software, Engineered to Work Together