-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Exception running bazel coverage on java tests #4398
Comments
Testing it on another package, I see a different exception
Full output:
|
The first exception does not occur if I pass "--jobs 1", so presumably this is a bug in the interaction with concurrent workers. If you have any guidance or links as to how to debug / develop a fix for it I'd be happy to try to put together a pull request. Looking at the second one.. |
Any feedback on this? |
I tried with bazel 0.10.0 and these errors still occur in the same way |
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. |
(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.) |
Are there any more coverage errors you get now with |
Yes, the concurrency-related error still occurs as before when I run coverage on the ~25 test suite targets in our util directory. It does not occur with --jobs=1. Is that sufficient to diagnose? |
Can you tell me more about your setup? How are your tests/libraries structured? |
I have about 30 test packages under util, with a representative illustration of one in and I'm running them like
which passes (as expected) because it's only one test. I believe if I created 30 (or at least a number of) different packages it would reproduce. Here is a latest example of failure, where one failed to build, and the rest were skipped:
Based on this error:
This is supported by the fact that running the coverage using --jobs=1 causes it to work. Does that seem plausible? Or is it something in our setup / bazel.rc that is causing the test suites to get mixed up? |
Yes, it's totally plausible. I'll try to reproduce. Thanks for the info! |
I managed to get a couple of errors that seem related with the bazel java tests. Both commands are successful if used with
|
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? |
Still happening on 0.13.0 |
Still happening on 0.14.0 @iirina , since I'm not sure you saw my previous question, can you advise why it's a low priority when it seems like a major blocker for calling java coverage "production ready"? How do folks in the bazel project run coverage? I can't imagine you pass --jobs 1 |
Hi Rob, I'm sorry for the silence and the terrible state of coverage. A bit of coverage context: Bazel rolled-out coverage in a poor, minimalist way and unfortunately it was not production ready (see #1118). This quarter we had the resources to prioritize working on coverage and we now have a design doc for improving it. Also unfortunately, Bazel doesn't run coverage for itself ATM. That will change (see one of the requirements in the doc). All in all, the situation is bad and we are now trying to make it better. I'm working on a fix for this issue right now. Given that the first RC was already cut for Bazel 0.15.0 already started, the fix should be in 0.16.0. |
Hi Irina, |
@iirina The concurrency-related error has indeed gone away! That's a big step and will fix the vast majority of our issues. Thank you very much! I do still see the other error from the original report. It seems to be triggered by instrumentation of an error-prone check. Here's the scenario:
and
Here's the full error:
It seems like coverage instrumentation should ignore java_plugin targets? |
Yay!
Can you open a new issue for this bug and cc me on it? In the meantime could you also try running coverage with |
Sadly, I do get the same error. Opened #5426, thank you! |
for each test instead of the same directory for all the tests. The previous implementation was using one directory for instrumenting the classes of a jar. For each each jar the metadata directory was deleted if it already existed. This is problematic for local execution when multiple tests are run in parallel because some threads will try to delete the directory and some will try to perform read/write operations on it. This is an important fix for Bazel coverage users. Fixes bazelbuild#4398. RELNOTES: Java coverage works now with multiple jobs. PiperOrigin-RevId: 199764483
for each test instead of the same directory for all the tests. The previous implementation was using one directory for instrumenting the classes of a jar. For each each jar the metadata directory was deleted if it already existed. This is problematic for local execution when multiple tests are run in parallel because some threads will try to delete the directory and some will try to perform read/write operations on it. This is an important fix for Bazel coverage users. Fixes bazelbuild#4398. RELNOTES: Java coverage works now with multiple jobs. PiperOrigin-RevId: 199764483
for each test instead of the same directory for all the tests. The previous implementation was using one directory for instrumenting the classes of a jar. For each each jar the metadata directory was deleted if it already existed. This is problematic for local execution when multiple tests are run in parallel because some threads will try to delete the directory and some will try to perform read/write operations on it. This is an important fix for Bazel coverage users. Fixes bazelbuild#4398. RELNOTES: Java coverage works now with multiple jobs. PiperOrigin-RevId: 199764483
Description of the problem / feature request:
"bazel coverage" produces an exception internal to bazel
The directory being complained about does not exist under output_path
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
#1118
The text was updated successfully, but these errors were encountered: