Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4211181

(verifier) VerifyError using custom class loader

XMLWordPrintable

    • 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)
      ======================================================================

            wtaosunw Wei Tao (Inactive)
            apalanissunw Anand Palaniswamy (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: