Name: vsR10008 Date: 06/29/2000



Class format checker doesn't reject classes with duplicated fields or
methods because of the error in heap sort algorithm implementation.

JVM spec reads:

4.5 Fields
...
No two fields in one class file may have the same name and descriptor (?4.3.2)
...
4.6 Methods
...
No two methods in one class file may have the same name and descriptor (?4.3.3)
...

Thus classfile which contains duplicated fields and/or methods should be rejected,
but in fact the result depends on the order of fields or methods in classfile.

Classes t1 and t2 in example below are nearly equal except of the different
order of their fields. Class t1 is rejected but t2 is loaded successfully.

----------------------------------------------------------------- t1.jasm --
super class t1
{
Field f:I;
Field f:I;
Field g:I;
Field h:I;

public static Method main:"([Ljava/lang/String;)V"
stack 0 locals 1
{
return;
}

} // end Class t1

----------------------------------------------------------------- t2.jasm --
super class t2
{
Field f:I;
Field g:I;
Field f:I;
Field h:I;

public static Method main:"([Ljava/lang/String;)V"
stack 0 locals 1
{
return;
}

} // end Class t2
--------------------------------------------------------------------------

Execution log:
> uname -a
SunOS novo12 5.7 Generic_Patch sun4u sparc SUNW,Ultra-2
> java -version
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, interpreted mode)
> jasm t1.jasm t2.jasm
> java t1
Exception in thread "main" java.lang.ClassFormatError: t1 (Repeative field name/signature)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:486)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
> java t2
> echo $status
0

The same behavior may be demonstrated for methods too. We tested class which has
4 methods (init, main and two duplicated) in all possible order combinations
(24 combinations in total) and found out that JVM was failed to reject class in 50%
of cases.

This bug is reproduced in JDK 1.2 and higher, both classic and HotSpot VMs.
Note, that JVMs in JDK 1.0-1.1.8 don't detect duplicated members.

It looks like duplicated members detection depends on the fields/methods ordering.
We suppose that the bug occurs because of error in implementation of heap sort
algorithm in class format checker.

We believe that the following fix will help.
In file /src/share/native/common/check_format.c (line 1902) variable secondChild
should be initialized like this

    int secondChild = firstChild + 2;

instead of

    int secondChild = firstChild + 4;

======================================================================