-
Bug
-
Resolution: Fixed
-
P4
-
1.1.6
-
1.2.1
-
generic, x86
-
generic, windows_nt
Name: ap32198 Date: 02/12/99
Our application loads classes with a custom
class loader. For some large classes we get
a VerifyError on these classes when using a
custom class loader (a class that extends ClassLoader).
If you run "java -verbose", the error looks like:
VERIFIER ERROR bad.service(Latg/servlet/DynamoHttpServletRequest;Latg/servlet/Dy
namoHttpServletResponse;)V:
Register 34 contains wrong type
[Loaded java/lang/VerifyError.class from /usr/local/jdk1.1.5/bin/../lib/classes.
zip]
java.lang.VerifyError: bad
at java.lang.ClassLoader.resolveClass(ClassLoader.java)
at CustomClassLoader.loadClass(CustomClassLoader.java:44)
at java.lang.ClassLoader.loadClass(ClassLoader.java)
at LoadClassWithLoader.main(LoadClassWithLoader.java:8)
This same class loads fine if the .class file is
in the normal classpath (and thus does not use
the custom class loader). Minor, seemingly innocuous
changes to the .java file cause the test case
to work.
I have reproduced this problem on NT (jdk1.1.5,
jdk1.1.6, jdk1.2beta3) and Solaris (jdk1.1.5).
This test case does seem to work on Solaris
jdk1.2beta3, but it's possible that small changes
to the .java file might cause it to fail there
too.
I've put up a .jar file with the test case on:
http://people.atg.com/~jjv/verifyError.jar
To run the test case, unjar this file and either
type "runme.bat" (windows) or "sh runme.sh" (Solaris)
The test case contains source to our custom class
loader and the class which causes the error. There
is also a jar file of classes which the "bad"
class depends upon (I was unable to shrink the
test case due to the sporadic nature of this bug).
To me this appears to be a serious problem with
class loading/verification in the java VM.
(Review ID: 29767)
======================================================================
Our application loads classes with a custom
class loader. For some large classes we get
a VerifyError on these classes when using a
custom class loader (a class that extends ClassLoader).
If you run "java -verbose", the error looks like:
VERIFIER ERROR bad.service(Latg/servlet/DynamoHttpServletRequest;Latg/servlet/Dy
namoHttpServletResponse;)V:
Register 34 contains wrong type
[Loaded java/lang/VerifyError.class from /usr/local/jdk1.1.5/bin/../lib/classes.
zip]
java.lang.VerifyError: bad
at java.lang.ClassLoader.resolveClass(ClassLoader.java)
at CustomClassLoader.loadClass(CustomClassLoader.java:44)
at java.lang.ClassLoader.loadClass(ClassLoader.java)
at LoadClassWithLoader.main(LoadClassWithLoader.java:8)
This same class loads fine if the .class file is
in the normal classpath (and thus does not use
the custom class loader). Minor, seemingly innocuous
changes to the .java file cause the test case
to work.
I have reproduced this problem on NT (jdk1.1.5,
jdk1.1.6, jdk1.2beta3) and Solaris (jdk1.1.5).
This test case does seem to work on Solaris
jdk1.2beta3, but it's possible that small changes
to the .java file might cause it to fail there
too.
I've put up a .jar file with the test case on:
http://people.atg.com/~jjv/verifyError.jar
To run the test case, unjar this file and either
type "runme.bat" (windows) or "sh runme.sh" (Solaris)
The test case contains source to our custom class
loader and the class which causes the error. There
is also a jar file of classes which the "bad"
class depends upon (I was unable to shrink the
test case due to the sporadic nature of this bug).
To me this appears to be a serious problem with
class loading/verification in the java VM.
(Review ID: 29767)
======================================================================