Thanks a lot, that works very well. I had already redefined all modules I encountered, but was not adding the agent JAR to the bootstrap search path.
Fabian On Tue, May 11, 2021 at 5:18 PM Alan Bateman <alan.bate...@oracle.com> wrote: > On 11/05/2021 16:10, Fabian Meumertzheim wrote: > > I am currently working on a JVM fuzzer ( > > https://github.com/CodeIntelligenceTesting/jazzer/) and would like to > apply > > it also to classes delivered with the JDK, e.g. the image parsers in > > javax.imageio.* in the java.desktop module. The fuzzer uses a Java agent > to > > add coverage instrumentation (similar to JaCoCo) to classes at runtime. > > > > As opposed to JaCoCo, for technical reasons the fuzzer needs to inject > > bytecode referencing a public static byte[] field defined on a class of > the > > agent. Since -javaagent does not support Java modules, this class will be > > part of the unnamed module and thus can't be "opened" to other modules, > > leading to a "NoClassDefFoundError" when the bytecode is injected into a > > class in a different module, e.g. java.desktop. > > > > Is there any way to have a Java agent open up a class for direct access > by > > named modules? I have full control over the JVM args within the fuzzer, > but > > haven't found a way to achieve this. > I don't think this a modules issue, it's more likely a visibility issue > because the boot class loader does not delegate to the application class > loader. If you are instrumenting classes in java.desktop to call into > some supporting classes that the agent provides then you need those > class on the boot class path. > Instrumentation::appendToBootstrapClassLoaderSearch is the API for that. > You'll also need to use redefineModule to change java.desktop to read > the unnamed module of the boot class loader. > > -Alan >
