bazel: Exception running bazel coverage on java tests

Description of the problem / feature request:

“bazel coverage” produces an exception internal to bazel

$ bazel clean --expunge
INFO: Starting clean (this may take a while). Consider using --async if the clean takes more than several minutes.

$ bazel coverage --instrumentation_filter=//src/com/corp/profiles //test/com/corp/profiles:unit
...........
INFO: Analysed target //test/com/corp/profiles:unit (171 packages loaded).
INFO: Found 1 test target...
ERROR: /Users/robfig/alpha/src/com/corp/profileservice/validation2/error/BUILD:3:1: Building src/com/corp/profileservice/validation2/error/liberror.jar (3 source files) failed (Exit 1): java failed: error executing command
  (cd /private/var/tmp/_bazel_robfig/1db08896ecff7e5e96a745981c3b77e6/execroot/__main__ && \
  exec env - \
    LC_CTYPE=en_US.UTF-8 \
  external/local_jdk/bin/java -XX:+TieredCompilation '-XX:TieredStopAtLevel=1' -Xbootclasspath/p:external/bazel_tools/third_party/java/jdk/langtools/javac-9-dev-r4023-3.jar -jar external/bazel_tools/tools/jdk/JavaBuilder_deploy.jar @bazel-out/darwin-fastbuild/bin/src/com/corp/profileservice/validation2/error/liberror.jar-2.params)
java.nio.file.DirectoryNotEmptyException: bazel-out/darwin-fastbuild/coverage-metadata/com/corp/profileservice/completion
	at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:242)
	at sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103)
	at java.nio.file.Files.delete(Files.java:1126)
	at com.google.devtools.build.buildjar.instrumentation.JacocoInstrumentationProcessor$2.postVisitDirectory(JacocoInstrumentationProcessor.java:153)
	at com.google.devtools.build.buildjar.instrumentation.JacocoInstrumentationProcessor$2.postVisitDirectory(JacocoInstrumentationProcessor.java:143)
	at java.nio.file.Files.walkFileTree(Files.java:2688)
	at java.nio.file.Files.walkFileTree(Files.java:2742)
	at com.google.devtools.build.buildjar.instrumentation.JacocoInstrumentationProcessor.recursiveRemove(JacocoInstrumentationProcessor.java:141)
	at com.google.devtools.build.buildjar.instrumentation.JacocoInstrumentationProcessor.processRequest(JacocoInstrumentationProcessor.java:79)
	at com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.buildJar(SimpleJavaLibraryBuilder.java:140)
	at com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.run(SimpleJavaLibraryBuilder.java:118)
	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)
Target //test/com/corp/profiles:unit failed to build
INFO: Elapsed time: 111.911s, Critical Path: 39.00s
FAILED: Build did NOT complete successfully

Executed 0 out of 1 test: 1 fails to build.

$ bazel test //test/com/corp/profiles:unit
INFO: Analysed target //test/com/corp/profiles:unit (0 packages loaded).
INFO: Found 1 test target...
Target //test/com/corp/profiles:unit up-to-date:
  bazel-bin/test/com/corp/profiles/unit.jar
  bazel-bin/test/com/corp/profiles/unit
INFO: Elapsed time: 26.749s, Critical Path: 22.90s
INFO: Build completed successfully, 139 total actions
//test/com/corp/profiles:unit                                            PASSED in 5.5s

Executed 1 out of 1 test: 1 test passes.

The directory being complained about does not exist under output_path

$ bazel info
output_path: /private/var/tmp/_bazel_robfig/1db08896ecff7e5e96a745981c3b77e6/execroot/__main__/bazel-out

$ ls /private/var/tmp/_bazel_robfig/1db08896ecff7e5e96a745981c3b77e6/execroot/__main__/bazel-out/darwin-fastbuild/coverage-metadata/com/corp/profileservice/completion
ls: /private/var/tmp/_bazel_robfig/1db08896ecff7e5e96a745981c3b77e6/execroot/__main__/bazel-out/darwin-fastbuild/coverage-metadata/com/corp/profileservice/completion: No such file or directory

Feature requests: what underlying problem are you trying to solve with this feature?

Run java tests with coverage enabled

Bugs: what’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

I don’t have an open source reproducer. I was hoping the stack trace would be enough

What operating system are you running Bazel on?

Mac OS High Sierra

What’s the output of `bazel info release`?

release 0.9.0

Have you found anything relevant by searching the web?

This appears to be the main discussion about coverage, but it seems to indicate that java coverage is expected to be in working order https://github.com/bazelbuild/bazel/issues/1118

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 2
Comments: 21 (8 by maintainers)

Commits related to this issue

Make JavaBuilder use a unique coverage metadata directory for each test instead of the same directory for all the tests. The previous implementation was using one directory for instrumenting the clas... — committed to yext/bazel by iirina 6 years ago
Make JavaBuilder use a unique coverage metadata directory for each test instead of the same directory for all the tests. The previous implementation was using one directory for instrumenting the clas... — committed to werkt/bazel by iirina 6 years ago
Make JavaBuilder use a unique coverage metadata directory for each test instead of the same directory for all the tests. The previous implementation was using one directory for instrumenting the clas... — committed to werkt/bazel by iirina 6 years ago

Most upvoted comments

Can I ask why this is not a higher priority? It seems like sort of a big issue in running coverage, and I was under the impression bazel considered java coverage to be production ready. For example, we have to run all of our coverage with j=1, which is a LOT slower than when running the equivalent bazel test at full parallelism. This results in none of the teams wanting to use it.

Or, is there a workaround that I’m not seeing? How do others run coverage without specifying j=1?

robfig on Mar 22, 2018

Hi Irina, Thanks for the response! The design doc looks very good, and I’m excited at the progress. This particular issue preventing us from being able to reliably run bazel coverage is the main pain point in the current situation, and we can migrate to the new format when it’s ready. I’m very pleased to hear that a fix is being worked on, and I’ll probably cut a personal release as soon as the fix goes in. Many thanks, Rob

robfig on Jun 5, 2018

(Looking at it again, I figured out that the NoClassDefFoundError was caused by the java_test depending on a java_binary target (accidentally) instead of java_library. It began working after correcting that.)

robfig on Feb 5, 2018

Running with --experimental_java_coverage solves the NoClassDefFoundError but not the java.nio.file.DirectoryNotEmptyException. At least this means I can run tests with --jobs 1 and have them succeed. Wonderful.