inst is null after v3.0.1

[cpovirk]

@cpovirk I am encountering the same issue with JDK 17 when using version v3.4.4. It appears to be related to changes in the Premain-Class definition within the MANIFEST.MF file, as the same error occurs across all versions after v3.0.1.

Below is the stack trace I am receiving:

Caused by: java.lang.NullPointerException: Cannot invoke "java.lang.instrument.Instrumentation.retransformClasses(java.lang.Class[])" because "inst" is null
        at com.google.monitoring.runtime.instrumentation.ConstructorInstrumenter.instrumentClass(ConstructorInstrumenter.java:85)

Originally posted by @dbshah12 in #58

[cpovirk]

I see what you mean about the Premain-Class definition:

• 3.0.1: Premain-Class: com.google.monitoring.runtime.instrumentation.AllocationInstrumenter
• 3.1.0: Premain-Class: com.google.monitoring.runtime.instrumentation.AllocationInstrumenterBootstrap

AllocationInstrumenterBootstrap is a class that was newly introduced in 3.1.0. It arrived in e2258bf. It's possible that something went wrong there. (I see a subsequent migration to Bazel in 5cecf4f. But that didn't land until 3.2.0, so it wouldn't explain a problem that started in 3.1.0, though it's always possible that it made things worse/different.)

I thought maybe it was suspicious that our tests still use plain AllocationInstrumenter, not AllocationInstrumenterBootstrap. But when I changed that line to AllocationInstrumenterBootstrap, I started seeing failures that refer to AllocationInstrumenterBootstrapBootstrap (with double Bootstrap), so the test rule might already be adding Bootstrap for us.

I don't know enough about instrumentation to know what to try here, nor even how to evaluate whether a proposed change is safe for users for whom things currently work :(

[dbshah12]

yes @cpovirk

Not sure if it is related or not, but there is a difference after 3.0.1. I try to run a small sample code:

public class AllocationTest {
  private static final Set<Class<? extends Throwable>> FATAL_THROWABLES =
      new ImmutableSet.Builder<Class<? extends Throwable>>()
         .add(Error.class)
          .add(LinkageError.class)
          .add(IOError.class)
          .add(ServiceConfigurationError.class)
          .add(ThreadDeath.class)
          .add(VirtualMachineError.class)
          .build();
  public static void main(String[] args) {
    System.out.println("Starting memory allocation test...");

    try {

      for (Class<? extends Throwable> throwable : FATAL_THROWABLES) {
        System.out.println(">>>>>>"+throwable);
        ConstructorInstrumenter.instrumentClass(
            throwable,
            (Throwable t) -> System.out.println("Constructing fatal throwable: " + t.getClass().getName()));
      }
      if(true){
        try {
            throw new IOError(new Exception("Test IOError"));
        } catch (IOError e) {
          System.out.println("SUCCESS : Constructed the fatal throwable");
          return;
        }
      }

      System.out.println("Instrumentation available, proceeding with class instrumentation");

    } catch (Exception e) {
      System.out.println("Failed to access instrumentation: " + e.getMessage());
      e.printStackTrace();
    }
  }
}

When I run version 3.0.1, I get the error Constructing fatal throwable: java.io.IOError twice — once for the IOError and once for the Error. But with version 3.3.4, it shows up only once, which is correct.

My main point is that if I am creating a small Java class and run it with -javaagent:java-allocation-instrumenter-3.3.4.jar=manualOnly, but when I am passing -javaagent:java-allocation-instrumenter-3.3.4.jar=manualOnly with my tomcat jar calling, which is calling my war, and further in the war it is calling ConstructorInstrumenter.instrumentClass` there I am getting inst is null, why so?

[dbshah12]

For the latest version, we are calling the premain method of AllocationInstrumenterBootstrap:

public static void premain(String agentArgs, Instrumentation inst) {
    try {
      String resourceName = "com/google/monitoring/runtime/instrumentation/AllocationInstrumenterBootstrap.class";
      URL url = ClassLoader.getSystemResource(resourceName);
      JarFile jarfile = ((JarURLConnection)url.openConnection()).getJarFile();
      inst.appendToBootstrapClassLoaderSearch(jarfile);
      Class<?> premainClass = Class.forName("com.google.monitoring.runtime.instrumentation.AllocationInstrumenter");
      Method pm = premainClass.getDeclaredMethod("premain", String.class, Instrumentation.class);
      pm.invoke((Object)null, agentArgs, inst);
    } catch (Exception var7) {
      Exception e = var7;
      throw new RuntimeException(e);
    }
  }

Which calls the premain method of AllocationInstrumenter:

public static void premain(String agentArgs, Instrumentation inst) {
    AllocationRecorder.setInstrumentation(inst);

    try {
      Class.forName("sun.security.provider.PolicyFile");
      Class.forName("java.util.ResourceBundle");
      Class.forName("java.util.Date");
    } catch (Throwable var3) {
    }

    if (!inst.isRetransformClassesSupported()) {
      System.err.println("Some JDK classes are already loaded and will not be instrumented.");
    }

    if (AllocationRecorder.class.getClassLoader() != null) {
      canRewriteBootstrap = false;
      System.err.println("Class loading breakage: Will not be able to instrument JDK classes");
    } else {
      canRewriteBootstrap = true;
      List<String> args = Arrays.asList(agentArgs == null ? new String[0] : agentArgs.split(","));
      ConstructorInstrumenter.subclassesAlso = args.contains("subclassesAlso");
      inst.addTransformer(new ConstructorInstrumenter(), inst.isRetransformClassesSupported());
      if (!args.contains("manualOnly")) {
        bootstrap(inst);
      }

    }
  }

For v3.0.1, we were calling the premain method of AllocationInstrumenter directly:

public static void premain(String agentArgs, Instrumentation inst) {
    AllocationRecorder.setInstrumentation(inst);

    // Force eager class loading here; we need these classes in order to do
    // instrumentation, so if we don't do the eager class loading, we
    // get a ClassCircularityError when trying to load and instrument
    // this class.
    try {
      Class.forName("sun.security.provider.PolicyFile");
      Class.forName("java.util.ResourceBundle");
      Class.forName("java.util.Date");
    } catch (Throwable t) {
      // NOP
    }

    if (!inst.isRetransformClassesSupported()) {
      System.err.println("Some JDK classes are already loaded and " +
          "will not be instrumented.");
    }

    // Don't try to rewrite classes loaded by the bootstrap class
    // loader if this class wasn't loaded by the bootstrap class
    // loader.
    if (AllocationRecorder.class.getClassLoader() != null) {
      canRewriteBootstrap = false;
      // The loggers aren't installed yet, so we use println.
      System.err.println("Class loading breakage: " +
          "Will not be able to instrument JDK classes");
      return;
    }

    canRewriteBootstrap = true;
    List<String> args = Arrays.asList(
        agentArgs == null ? new String[0] : agentArgs.split(","));

    // When "subclassesAlso" is specified, samplers are also invoked when
    // SubclassOfA.<init> is called while only class A is specified to be
    // instrumented.
    ConstructorInstrumenter.subclassesAlso = args.contains("subclassesAlso");
    inst.addTransformer(new ConstructorInstrumenter(),
        inst.isRetransformClassesSupported());

    if (!args.contains("manualOnly")) {
      bootstrap(inst);
    }
  }

For v3.3.4, instbecoming null for a complex structure, where it is working fine with v3.0.1. Any idea why? Does a change in the premain code ofAllocationInstrumenter`cause this?

[dbshah12]

Hi @cpovirk

This seems like a classloader isolation issue, which started happening after 3.1.0, and there is no big change in 3.1.0 except Bootstrap.java.in addition (java-allocation-instrumenter-3.0.1...dbshah12:allocation-instrumenter:java-allocation-instrumenter-3.1.0). Is something missing here which is leading to a classloader isolation issue?

I want to upgrade my project to Java 17, but for that I need to upgrade java-allocation-instrumenter, but the latest version has this classloader isolation issue. Is there any workaround or hack to fix this?