bazel: `repo_mapping` file is generated by conflicting actions
Description of the bug:
ERROR: file 'app.release_deps_lint_test_script.repo_mapping' is generated by these conflicting actions:
Label: //:app.release_deps_lint
RuleClass: apple_verification_test rule
JavaActionClass: class com.google.devtools.build.lib.analysis.RepoMappingManifestAction
Configuration: b20c4f686aacafa27460b3c60d2f9d88d1c7b116c35cf69d3e32d36fe70be31f, 61221742bd234fe9c9154be231196cc1037b1df27cd5fe89863d6fc3faf3b1c7
Mnemonic: RepoMappingManifest
Action key: 6506cd03fbf9ab0f9aa39694cd03e9d4aba8780eabd335df9ad2fb02890234ef, a27b7329291cba2e8dac45a3e4f78183e40a5bbc6a632d209e31e5e4971b629a
Progress message: Writing repo mapping manifest for //:app.release_deps_lint
Action describeKey: (null)
PrimaryInput: (null)
PrimaryOutput: File:[[<execution_root>]bazel-out/darwin_arm64-fastbuild/bin]app.release_deps_lint_test_script.repo_mapping
Owner information: RealConfiguredTargetKey{label=//:app.release_deps_lint, config=BuildConfigurationKey[b20c4f686aacafa27460b3c60d2f9d88d1c7b116c35cf69d3e32d36fe70be31f]}, RealConfiguredTargetKey{label=//:app.release_deps_lint, config=BuildConfigurationKey[61221742bd234fe9c9154be231196cc1037b1df27cd5fe89863d6fc3faf3b1c7]}
MandatoryInputs: are equal
Outputs: are equal
ERROR: com.google.devtools.build.lib.actions.MutableActionGraph$ActionConflictException: for app.release_deps_lint_test_script.repo_mapping, previous action: action 'Writing repo mapping manifest for //:app.release_deps_lint', attempted action: action 'Writing repo mapping manifest for //:app.release_deps_lint'
This error is produced intermittently in our project. In the failure case the diff of the configurations mentioned in above is:
INFO: Displaying diff between configs 1aaa43b86dc7ca2975461a460eea09f521c55088f3bcf51acc405cff20cc7078 and df2789a14be991566c2136d5d6ed0f14452c03a0f9e777baf1b4948388ada537
Displaying diff between configs 1aaa43b86dc7ca2975461a460eea09f521c55088f3bcf51acc405cff20cc7078 and df2789a14be991566c2136d5d6ed0f14452c03a0f9e777baf1b4948388ada537
FragmentOptions com.google.devtools.build.lib.analysis.test.TestConfiguration$TestOptions {
cache_test_results: NO, null
coverage_support: @bazel_tools//tools/test:coverage_support, null
experimental_cancel_concurrent_tests: false, null
experimental_fetch_all_coverage_outputs: false, null
experimental_retain_test_configuration_across_testonly: false, null
experimental_split_coverage_postprocessing: false, null
incompatible_check_sharding_support: false, null
incompatible_exclusive_test_sandboxed: true, null
runs_per_test: [(?:(?>.*)) Options: [1]], null
runs_per_test_detects_flakes: false, null
test_arg: [], null
test_filter: null, null
test_result_expiration: -1, null
test_runner_fail_fast: false, null
test_sharding_strategy: EXPLICIT, null
test_timeout: {short=PT1M, moderate=PT5M, long=PT15M, eternal=PT1H}, null
trim_test_configuration: true, null
use_target_platform_for_tests: false, null
zip_undeclared_test_outputs: true, null
}
It seems like passing --trim_test_configuration=false
works around this issue. I believe this was introduced in https://github.com/bazelbuild/bazel/commit/698a5142d2036f8ce5e35ed581fe58feb210f116 but it still repros on HEAD today.
What’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
This can be reproduced on macOS with this project: repro.zip by running ./repro.sh
. It cleans and builds multiple times since the issue is intermittent.
Which operating system are you running Bazel on?
macOS
What is the output of bazel info release
?
698a5142d2036f8ce5e35ed581fe58feb210f116
If bazel info release
returns development version
or (@non-git)
, tell us how you built Bazel.
bazelisk
What’s the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD
?
No response
Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 16 (8 by maintainers)
Commits related to this issue
- Fix OOM in `describeNestedSetFingerprint` `describedNestedSetFingerprint` appended a `StringBuilder` to itself in a loop instead of the actual item from the nested set, resulting in OOMs in `Runfiles... — committed to bazelbuild/bazel by fmeum a year ago
- Fix OOM in `describeNestedSetFingerprint` `describedNestedSetFingerprint` appended a `StringBuilder` to itself in a loop instead of the actual item from the nested set, resulting in OOMs in `Runfiles... — committed to iancha1992/bazel by fmeum a year ago
- Sort out of order transitive packages before adding. (#18666) PiperOrigin-RevId: 541656611 Change-Id: Ie6c365275003343dc2bf0520a305e005ec48550b — committed to bazelbuild/bazel by aoeui a year ago
- Fix OOM in `describeNestedSetFingerprint` `describedNestedSetFingerprint` appended a `StringBuilder` to itself in a loop instead of the actual item from the nested set, resulting in OOMs in `Runfiles... — committed to traversaro/bazel by fmeum a year ago
Sorry for the late response. I don’t check the email associated with this account frequently.
@lberki - yes, the results are streamed in as they arrive so the ordering is nondeterministic.
If sorting suffices here, @fmeum’s approach looks good with some slight modifications. I’ll draft a change.
@bazel-io fork 6.3.0
@bazel-io flag