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

Custom Class Loader Generates Incompatible type VerifyError

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P3
    • Resolution: Not an Issue
    • Affects Version/s: 1.1.8
    • Fix Version/s: None
    • Component/s: hotspot
    • Subcomponent:
    • CPU:
      generic
    • OS:
      generic

      Description

      THIS BUG REPORT IS FILED FOR SUBMISSION OF AN ESCALATION TO CTE.

      The customer has written a custom class loader which generates VerifyErrors at
      resolve time. The custom class loader is designed along the lines of the
      example presented by Sheng Liang and Gilad Bracha in their paper "Dynamic Class
      Loading in the Java Virtual Machine", and the code appears to be correct.

      No transformation is performed upon the classes loaded by the custom loader, and
      the classes are loaded without error by the primordial loader.

      The problem appears on both Solaris and win32, on 1.1.8 as well as 1.2. It appears when the code is compiled with any compiler version, and whether the
      JIT is turned on or off. When run with 1.2, the VerifyError appears as follows:

      java.lang.VerifyError: (class: com/ensemble/coordinator/CoordinatedObject, method: printCoordinationMode signature: (Lcom/ensemble/coordinator/utilities/DisplayStream;)V) Incompatible type for getting or setting field

      The error message can be traced to line 1992 of src/share/native/common/check_code.c in the 1.2 JVM source.

      Here is the code for the customer's class loader:

          public Class loadClass(String name, boolean resolve)
              throws ClassNotFoundException
          {
              Class c = null;

              if(isSystemClassName(name)) {
                  trace("<- <system> "+name);
                  return findSystemClass(name);
              }

              BasicClassDescriptor cd = BasicClassDescriptor.lookup(name);

              // transform the bytes if the class is coordinated
              if(cd.isCoordinated()) {
                  ClassFile cf = cd.getFile();
                  cf.augmentInline();
                  return install(cf, resolve);
              } else {
                  c = findSystemClass(name);
                  cd.setDescribedClass(c);
                  return c;
              }
          }

          public Class install(ClassFile cf, boolean resolve)
              throws ClassNotFoundException
          {
              Class installedClass = null;
              String className = cf.classDescriptor.className;

              try {
                  byte data[] = cf.getData();
                  installedClass = defineClass(className, data, 0, data.length);
                  cf.classDescriptor.setDescribedClass(installedClass);
                  if(resolve) {
                      resolveClass(installedClass);
                  }
              } catch (Throwable e) {
                  cf.verify();

                  // write myself for diagnosis
                  trace("INSTALL FAILED! "+className+", dumping to file");
                  try {
                      cf.write();
                  } catch(IOException e2) {
                      e2.printStackTrace();
                  }
                  WarningDialog.panic("class generator error: "+className, e);
              }
              return installedClass;
          }

      The customer's application is highly complex, and the customer has been unable
      to extract a workable test case. The customer's application can be found in
      the file /home/nrodin/cases/adaptec/716368/coordinator.tar. Packaged with the
      application are compile2.bat and run.bat for compiling and running the program
      on win32. These files will need to be modified to execute in your environment.

      Attached are ClassManager.java, which contains the above source, and test_output, a screen dump from running the application. Line 27 of test_output
      shows the class CoordinatedObject being loaded by the primordial loader (line 154 of ClassManager.java). On line 102, a VerifyError occurs when the same class is loaded by the custom class loader.

        Attachments

          Activity

            People

            • Assignee:
              gbrachasunw Gilad Bracha (Inactive)
              Reporter:
              nrodinsunw Nick Rodin (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Imported:
                Indexed: