Name: mf23781 Date: 05/20/99


The PostBeta8c release of rmi-iiop demonstrates a problem with the reflection algorithm in 118fcs.

To recreate the problem:
Install rmi-iiop extension
Change to the rmi-iiop test\src\share\classes\juicer directory
Compile the Applet server using: rmic -iiop AppletServer

In the JDK117 this will compile correctly but in the JDK118 fcs the program will crash, producing an application error e.g. "instruction at Ox1001053a referenced memory at 0x00000000. The memory could not be read".

JDK 1.1.8B JDK did not exhibit the problem, which appears to have been introduced in the 1.1.8C JDK after bug fix 4090364("make reflection checks conform to spec"). For 1.1.8C a change was made to the alorithm used in the reflect_is_assignable method in reflect.c; no change was made to the parameters passed or the return parameters. Importing the 1.1.8B algorithm into the 1.1.8C JDK and rebuilding it, produces a sucessful rmic compilation. This could be the candidate responsible.

The problem can also be recreated by running the 'testme' example in the rmi-iiop PostBeta8c release. This fails in the native method Class.isAssignableFrom() which is called with the following stack trace:

    "main" (TID:0xf700b0, sys_thread_t:0x87e7e0, Win32ID:0xf2, state:R) prio=5
        com.sun.rmi.io.ObjectStreamClass.lookupInternal(ObjectStreamClass.java:119)
        com.sun.rmi.io.ObjectStreamClass.lookup(ObjectStreamClass.java:94)
        com.sun.rmi.io.ObjectStreamField.<init>(ObjectStreamField.java:43)
        com.sun.rmi.io.ObjectStreamField.<init>(ObjectStreamField.java:80)
        com.sun.rmi.io.ObjectStreamClass.<init>(ObjectStreamClass.java:369)
        com.sun.rmi.io.ObjectStreamClass.lookupInternal(ObjectStreamClass.java:137)
        com.sun.rmi.io.ObjectStreamClass.lookup(ObjectStreamClass.java:94)
        com.sun.rmi.util.RepositoryId.createHashString(RepositoryId.java:555)
        com.sun.rmi.util.RepositoryId.createForJavaType(RepositoryId.java:704)
        com.sun.rmi.util.RepositoryId.createForAnyType(RepositoryId.java:798)
        sun.rmi.rmic.iiop.Type.setRepositoryID(Type.java:978)
        sun.rmi.rmic.iiop.CompoundType.initialize(CompoundType.java:743)
        sun.rmi.rmic.iiop.ValueType.initialize(ValueType.java:238)
        sun.rmi.rmic.iiop.ValueType.forValue(ValueType.java:101)
        sun.rmi.rmic.iiop.CompoundType.makeType(CompoundType.java:890)
        sun.rmi.rmic.iiop.CompoundType$Method.<init>(CompoundType.java:2189)
        sun.rmi.rmic.iiop.CompoundType.addAllMethods(CompoundType.java:1286)
        sun.rmi.rmic.iiop.AbstractType.initialize(AbstractType.java:153)
        sun.rmi.rmic.iiop.AbstractType.forAbstract(AbstractType.java:75)
        sun.rmi.rmic.iiop.CompoundType.makeType(CompoundType.java:845)
(truncated hereafter)

It turns out the code is checking if java.io.Serializable is assignable from rmic.NotAbstract (one of rmic test interface).
The code executes all the way to the C function ImplementsInterface() in "src/share/java/runtime/interpreter.c" where the value "imtable -> icount" in the class object of rmic.NotAbstract is retrieved. For unknown reason, imtable (Interface Method Table) is null, therefore an access violation occurs. Why the imtable is null for rmic.NotAbstract? Maybe the class object was not constructed correctly, or somehow the JVM wiped out some of its fields.

The tests were also run on Solaris 1.1.8L. Interesting enough, it also crashed (core dumped) with the same Java stack
trace and these additional dump:

SIGSEGV 11* segmentation violation
    si_signo [11]: SIGSEGV 11* segmentation violation
    si_errno [0]: Error 0
    si_code [1]: SEGV_MAPERR [addr: 0x0]

        stackbase=EFFFEC28, stackpointer=EFFFE338


(Review ID: 83303)

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