JDK-6191049 : java.lang.Instrumentation.redefineClass and -Xfuture cause VerifyError
  • Type: Bug
  • Component: core-svc
  • Sub-Component: tools
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2004-11-04
  • Updated: 2004-11-05
  • Resolved: 2004-11-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0Resolved
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing)


ADDITIONAL OS VERSION INFORMATION :
SunOS mary 5.9 Generic_117171-07 sun4u sparc SUNW,Sun-Blade-100


A DESCRIPTION OF THE PROBLEM :
VerifyError after redefining a class with java.lang.Instrumentation.redefineClass - but only if -Xfuture is also given to the JVM


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) javac *.java
2) jar cmf manif M.jar M.class
3) java -javaagent:M.jar N
4) java -Xfuture -javaagent:M.jar N

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Nothing is printed

ACTUAL -
See Error Message


ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "main" java.lang.VerifyError: (class: java/net/Socket, method: shutdownOutput signature: ()V) Illegal type in constant pool
        at N.main(N.java:4)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
-- N.java --
class N {
  public static void main(String[] args) {
      M.emptyRedefine(java.net.Socket.class);
      new java.net.Socket();
    }
}


-- M.java --
import java.io.*;
import java.lang.instrument.*;
public class M {
    static Instrumentation instrumentation;
    public static void emptyRedefine(Class cl) {
        try {
            ClassLoader cloader = cl.getClassLoader();
            if (cloader == null) {
                cloader = ClassLoader.getSystemClassLoader();
            }
            String className = cl.getName().replace('.', '/') + ".class";
            InputStream is = cloader.getResourceAsStream(className);
            ByteArrayOutputStream out = new ByteArrayOutputStream();
            int b;
            while ((b = is.read()) != -1) {
                out.write(b);
            }
            is.close();
            ClassDefinition[] classDefs = {
                new ClassDefinition(cl, out.toByteArray())
            };
            instrumentation.redefineClasses(classDefs);
        }
        catch (Exception e) {
            throw new RuntimeException(e);
        }
    }
    public static void premain(String args, Instrumentation instrument) {
        instrumentation = instrument;
    }
}

-- manif --
Premain-Class: M
Boot-Class-Path: ./M.jar
Can-Redefine-Classes: true
---------- END SOURCE ----------
###@###.### 11/4/04 23:04 GMT

Comments
WORK AROUND The workaround is to ensure that the class is linked before redefining it. In this test case insert cl.getDeclaredFields(); before redefineClasses is invoked will work. ###@###.### 2004-11-05 12:00:14 GMT
05-11-2004

EVALUATION Yes, this is a known issue in JDK5.0. If a class is redefined before it is linked then it can subsequently fail verification when the class is linked. The bug has been fixed as 5092850. ###@###.### 2004-11-05 12:00:13 GMT
05-11-2004