-
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
Using --experimental_split_coverage_postprocessing causes a RuntimeException #13185
Comments
This also happens with 4.1.0 and |
@oquenchil I also meet this problem in when I run
but run |
…g is used without experimental_fetch_all_coverage_outputs This closes bazelbuild#13185 According to bazelbuild@e411fa7, The flag --experimental_split_coverage_postprocessing depends on the flag --experimental_fetch_all_coverage_outputs being enabled, but if the former one is set without the latter one, Bazel throws a quite confusing NullPointerException. Now we throw an explicit exception with proper error message.
…g is used without experimental_fetch_all_coverage_outputs This closes bazelbuild#13185 According to bazelbuild@a445cda, The flag --experimental_split_coverage_postprocessing depends on the flag --experimental_fetch_all_coverage_outputs being enabled, but if the former one is set without the latter one, Bazel throws a quite confusing NullPointerException. Now we throw an explicit exception with proper error message.
According to a445cda , The error message should be more explicit, though. |
…g is used without experimental_fetch_all_coverage_outputs This closes bazelbuild#13185 According to bazelbuild@a445cda, The flag --experimental_split_coverage_postprocessing depends on the flag --experimental_fetch_all_coverage_outputs being enabled, but if the former one is set without the latter one, Bazel throws a quite confusing NullPointerException. Now we throw an explicit exception with proper error message.
…g is used without experimental_fetch_all_coverage_outputs This closes bazelbuild#13185 According to bazelbuild@a445cda, The flag --experimental_split_coverage_postprocessing depends on the flag --experimental_fetch_all_coverage_outputs being enabled, but if the former one is set without the latter one, Bazel throws a quite confusing NullPointerException. Now we throw an explicit exception with proper error message.
…g is used without experimental_fetch_all_coverage_outputs This closes bazelbuild#13185 According to bazelbuild@a445cda, The flag --experimental_split_coverage_postprocessing depends on the flag --experimental_fetch_all_coverage_outputs being enabled, but if the former one is set without the latter one, Bazel throws a quite confusing NullPointerException. Now we throw an explicit exception with proper error message.
…g is used without experimental_fetch_all_coverage_outputs This closes bazelbuild#13185 According to bazelbuild@a445cda, The flag --experimental_split_coverage_postprocessing depends on the flag --experimental_fetch_all_coverage_outputs being enabled, but if the former one is set without the latter one, Bazel throws a quite confusing NullPointerException. Now we throw an explicit exception with proper error message.
…g is used without experimental_fetch_all_coverage_outputs This closes bazelbuild#13185 According to bazelbuild@e411fa7, The flag --experimental_split_coverage_postprocessing depends on the flag --experimental_fetch_all_coverage_outputs being enabled, but if the former one is set without the latter one, Bazel throws a quite confusing NullPointerException. Now we throw an explicit exception with proper error message. Closes bazelbuild#16140. PiperOrigin-RevId: 479239693 Change-Id: I5afa0ae14a3f34a0a7b21fbf4badad3d1836da95
I just want to mention in case anyone else sees this that I've been encountering this problem with both of these flags enabled on bazel 5.2.3. Unfortunately I'm not able to try and contribute a minimal repro case, but if anyone else sees this they should chime in so that this issue could maybe be re-opened if it isn't actually resolved. |
Description of the problem:
With Bazel 4.0, using the
--experimental_split_coverage_postprocessing
flag causes errors and hard crashes. This probably shouldn't happen.Experimenting with
bazel coverage
on the abseil-cpp project.Using both flags without remote execution:
Using just one flag causes a stack-trace regardless of if you use this with remote execution or not:
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Run similar test commands locally, on your own RE infrastructure or follow the commands here:
#4685 (comment)
What operating system are you running Bazel on?
Linux 5.10.16-arch1-1
What's the output of
bazel info release
?release 4.0.0
Any other information, logs, or outputs that you want to share?
Perhaps somewhat related. Also contains an example in one of the recent comments you can follow to reproduce these errors.
#4685
Experimenting with
bazel coverage
on the abseil-cpp project:This currently returns empty
coverage.dat
files. Run without RE, the files contain data. May or may not be related.The text was updated successfully, but these errors were encountered: