New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiler exception running coverage: ClassNotFoundException: org.jacoco.agent.rt.internal_b0d6a23.Offline #5426

Open
robfig opened this Issue Jun 19, 2018 · 7 comments

Comments

Projects
None yet
3 participants
@robfig
Copy link

robfig commented Jun 19, 2018

"bazel coverage" fails at 0.14.1 and 4001ddd with a compiler exception. It happens with and without --experimental_java_coverage, and it seems to be triggered by instrumentation of an error-prone check.

Here's the scenario:

# //src/com/corp/util/i18n/BUILD
java_library(
    name = "i18n",
    srcs = glob(["*.java"]),
    exported_plugins = [
        "//src/com/corp/util/i18n/bugpatterns",
    ],
   ...  

and

# //src/com/corp/util/i18n/bugpatterns/BUILD
java_plugin(
    name = "bugpatterns",
    srcs = glob(["*.java"]),
   ...  

Here's the full error:

$ ../bazel/bazel-bin/src/bazel coverage test/com/corp/util/...

ERROR: /Users/robfig/alpha/src/com/corp/util/callable/BUILD:3:1: Building src/com/corp/util/callable/libcallable.jar (1 source file) failed (Exit 1): java failed: error executing command
  (cd /private/var/tmp/_bazel_robfig/1db08896ecff7e5e96a745981c3b77e6/execroot/corp && \
  exec env - \
    LC_CTYPE=en_US.UTF-8 \
  external/local_jdk/bin/java -Xbootclasspath/p:external/bazel_tools/third_party/java/jdk/langtools/javac-9+181-r4173-1.jar -jar external/bazel_tools/tools/jdk/JavaBuilder_deploy.jar @bazel-out/darwin-fastbuild/bin/src/com/corp/util/callable/libcallable.jar-2.params)
An exception has occurred in the compiler ((version info not available)). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you.
java.util.ServiceConfigurationError: com.google.errorprone.bugpatterns.BugChecker: Provider com.corp.util.i18n.bugpatterns.I18nNonConstant could not be instantiated
	at java.util.ServiceLoader.fail(ServiceLoader.java:232)
	at java.util.ServiceLoader.access$100(ServiceLoader.java:185)
	at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:384)
	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
	at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
	at com.google.common.collect.TransformedIterator.next(TransformedIterator.java:47)
	at com.google.errorprone.scanner.ScannerSupplier.fromBugCheckerClasses(ScannerSupplier.java:71)
	at com.google.errorprone.ErrorPronePlugins.loadPlugins(ErrorPronePlugins.java:47)
	at com.google.errorprone.ErrorProneAnalyzer.lambda$scansPlugins$0(ErrorProneAnalyzer.java:76)
	at com.google.common.base.Suppliers$NonSerializableMemoizingSupplier.get(Suppliers.java:164)
	at com.google.errorprone.ErrorProneAnalyzer.finished(ErrorProneAnalyzer.java:152)
	at com.google.devtools.build.buildjar.javac.plugins.errorprone.ErrorPronePlugin.postFlow(ErrorPronePlugin.java:110)
	at com.google.devtools.build.buildjar.javac.BlazeJavaCompiler.flow(BlazeJavaCompiler.java:112)
	at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1363)
	at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:959)
	at com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:100)
	at com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:142)
	at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:96)
	at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:90)
	at com.google.devtools.build.buildjar.javac.BlazeJavacMain.compile(BlazeJavacMain.java:110)
	at com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder$2.invokeJavac(SimpleJavaLibraryBuilder.java:121)
	at com.google.devtools.build.buildjar.ReducedClasspathJavaLibraryBuilder.compileSources(ReducedClasspathJavaLibraryBuilder.java:54)
	at com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.compileJavaLibrary(SimpleJavaLibraryBuilder.java:124)
	at com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.run(SimpleJavaLibraryBuilder.java:132)
	at com.google.devtools.build.buildjar.BazelJavaBuilder.processRequest(BazelJavaBuilder.java:105)
	at com.google.devtools.build.buildjar.BazelJavaBuilder.runPersistentWorker(BazelJavaBuilder.java:67)
	at com.google.devtools.build.buildjar.BazelJavaBuilder.main(BazelJavaBuilder.java:45)
Caused by: java.lang.NoClassDefFoundError: org/jacoco/agent/rt/internal_b0d6a23/Offline
	at com.corp.util.i18n.bugpatterns.I18nNonConstant.$jacocoInit(I18nNonConstant.java)
	at com.corp.util.i18n.bugpatterns.I18nNonConstant.<clinit>(I18nNonConstant.java)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at java.lang.Class.newInstance(Class.java:442)
	at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
	... 24 more
Caused by: java.lang.ClassNotFoundException: org.jacoco.agent.rt.internal_b0d6a23.Offline
	at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	... 32 more
INFO: Elapsed time: 18.145s, Critical Path: 8.44s
INFO: 14 processes: 10 darwin-sandbox, 1 local, 3 worker.
FAILED: Build did NOT complete successfully

It seems like coverage instrumentation should ignore java_plugin targets.

This is a follow-up of #4398

@iirina

This comment has been minimized.

Copy link
Contributor

iirina commented Jul 11, 2018

@cushon I'm a bit puzzled by what happens here, do you have any idea what is causing this error?

@cushon

This comment has been minimized.

Copy link
Contributor

cushon commented Jul 23, 2018

When JavaBuilder loads plugins it uses a non-standard classloader that prevents classes from JavaBuilder 'leaking' on to the plugin classpath:

private static class ClassloaderMaskingFileManager extends JavacFileManager {

Maybe those are interfering with jacoco?

It seems suspicious that the plugins are being instrumented at all, though. Do you expect instrumentation to be applied to host deps (like java_library.exported_plugins)?

@iirina

This comment has been minimized.

Copy link
Contributor

iirina commented Jul 24, 2018

It seems suspicious that the plugins are being instrumented at all, though. Do you expect instrumentation to be applied to host deps (like java_library.exported_plugins)?

IMO they should not be instrumented, but java_plugin has almost the same implementation as java_library. It looks like they are instrumented and I was wondering how we got away with it until now. My guess is the plugins are usually filtered away since they are in different packages. @robfig are you using --instrumentation_filter? You can also use this flag to exclude targets. Maybe the filter will temporarily fix this until we get a proper fix in.

@robfig

This comment has been minimized.

Copy link

robfig commented Jul 28, 2018

Yep, we can avoid running coverage on the plugin as a workaround. Thanks

@iirina

This comment has been minimized.

Copy link
Contributor

iirina commented Aug 22, 2018

@robfig Can you tell me more about the setup? I couldn't replicate yet. Do you have a java_test that depends on the java_library //src/com/corp/util/i18n:i18n? Does it use the exported plugin? How does //src/com/corp/util/callable:callable come into play in this scenario?

@robfig

This comment has been minimized.

Copy link

robfig commented Aug 23, 2018

I think the key thing is that a java_plugin is included in the bazel coverage command. In this case, our i18n package exports a plugin to identify common errors in using it.

So:
src/com/corp/util/i18n:i18n is a java library
src/com/corp/util/i18n/bugpatterns:bugpatterns is a java_plugin

bazel coverage src/com/corp/util/... fails because "bazel coverage src/com/corpo/util/i18n/bugpatterns" fails.

Assuming I am correct, the proposed solution is to ignore java_plugin targets when instrumenting code, or filter them out entirely when running coverage.

@robfig

This comment has been minimized.

Copy link

robfig commented Aug 23, 2018

(If that doesn't seem right or you can't immediately reproduce, I'm happy to put one together. I thought it would it would reproduce quickly/easily)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment