JDK-8336165 : sun.instrument.TransformerManager eats up exceptions thrown by ClassFileTransformer.transform() method
  • Type: Bug
  • Component: core-svc
  • Sub-Component: java.lang.instrument
  • Affected Version: 24
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2024-07-11
  • Updated: 2025-01-07
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
tbdUnresolved
Related Reports
Relates :  
Relates :  
Description
The sun.instrument.TransformerManager.transform() method implementation, currently has this:

    try {
        transformedBytes = transformer.transform(   module,
                                                    loader,
                                                    classname,
                                                    classBeingRedefined,
                                                    protectionDomain,
                                                    bufferToUse);
    }
    catch (Throwable t) {
        // don't let any one transformer mess it up for the others.
        // This is where we need to put some logging. What should go here? FIXME
    }

As you will notice, anything thrown from the ClassFileTransformer's transform() method gets eaten up in the catch block without it ever being reported. There's even a FIXME code comment about it.

Addressing this may not be straightforward since java.lang.instrument.Instrument.addTransformer(...) notes (among other things):

> If a transformer throws an exception during execution, the JVM will still call the other registered transformers in order.

So it might need some additional thought on how/when these exceptions can be reported.

Comments
> Logging could be disruptive though - as I mentioned there could be transforms silently and harmlessly failing "out there" and any new logging would be disruptive. I think we should explore it, esp. if opt-in as that would be more targeted than using -Xlog:exceptions. > Doesn't that violate the requirement that exceptions are to be ignored and the pipeline of transformers continued to be applied? If we change retransformClass/redefineClasses to propagate error/exceptions then it would be a spec update and behavior change. I think it should be explored as it doesn't have all the same constraints as load time instrumentation.
11-07-2024

Logging could be disruptive though - as I mentioned there could be transforms silently and harmlessly failing "out there" and any new logging would be disruptive. > and would have the positive effect of aborting the pipeline of transformers before the class bytes are redefined. Doesn't that violate the requirement that exceptions are to be ignored and the pipeline of transformers continued to be applied?
11-07-2024

This dates back to the original implementation for JSR 163 and JDK 5, it should have been given more attention at the time. For load time instrumentation/transformation (as in the upcall from the CFLH), then I think the only thing can be done here is to log the exception that is currently swallowed. This logging would need to be done in native code or via a call into the VM as you can't run arbitrary Java/logging code without side effects. For dynamic instrumentation or retransformation (as in calls to Instrumentation.retransformClasses or legacy redefineClasses) then we could potentially propagate errors or unchecked exceptions to the caller. These methods can potentially throw linkage error when the class bytes produced by the pipeline of transformers is "bad", and other exceptions are possible too. So while it would be a behavior change to propagate an error/exception thrown by the transform method, it wouldn't be too surprising, and would have the positive effect of aborting the pipeline of transformers before the class bytes are redefined.
11-07-2024

Yes it is non trivial coming up with an error reporting mechanism in such circumstances. These exceptions should not propagate and potentially kill the thread performing the transformation. And there is no defined logging facility for this API. Suddenly printing the exception to out/err may result in existing "bad" but harmless transformer errors causing unexpected output pollution.
11-07-2024