bazel: Conflicting actions for `cc_proto_library` with transition in Starlark rule dependency

Description of the problem / feature request:

As of 7acf9ea3fea4850d21114d84fbc5b663d105d3c7, Bazel generates conflicting actions when a custom Starlark rule depends on a cc_proto_library target in the exec configuration if there is a transition applied to the library.

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

$ cat WORKSPACE
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "com_google_protobuf",
    sha256 = "7892a35d979304a404400a101c46ce90e85ec9e2a766a86041bb361f626247f5",
    strip_prefix = "protobuf-3.16.0",
    url = "https://github.com/protocolbuffers/protobuf/archive/v3.16.0.tar.gz",
)

load("@com_google_protobuf//:protobuf_deps.bzl", "protobuf_deps")

protobuf_deps()

$ cat BUILD.bazel
load(":rules.bzl", "exec_with_library_dep", "apply_transition")

proto_library(
    name = "proto",
    srcs = ["empty.proto"],
    deps = [],
)

cc_proto_library(
    name = "cc_proto",
    deps = [":proto"],
)

apply_transition(
    name = "cc_proto_with_transition",
    native_target = ":cc_proto",
)

exec_with_library_dep(
    name = "error",
    out = "dummy.gen",
    library = ":cc_proto_with_transition",
)

$ touch empty.proto

$ cat rules.bzl
_COPT_BUILD_SETTING = "//command_line_option:copt"

def _set_foobar_copt(settings, attr):
    return {_COPT_BUILD_SETTING: ["-DFOOBAR"]}

set_foobar_copt = transition(
    implementation = _set_foobar_copt,
    inputs = [],
    outputs = [_COPT_BUILD_SETTING],
)

def _apply_transition_impl(ctx):
    pass

apply_transition = rule(
        implementation = _apply_transition_impl,
        attrs = {
            "native_target": attr.label(
                cfg = set_foobar_copt,
            ),
            "_allowlist_function_transition": attr.label(
                default = "@bazel_tools//tools/whitelists/function_transition_whitelist",
            ),
        },
    )


def _exec_with_library_dep_impl(ctx):
    ctx.actions.write(ctx.outputs.out, "")

exec_with_library_dep = rule(
    _exec_with_library_dep_impl,
    attrs = {
        "library": attr.label(
            mandatory = True,
            cfg = "exec",
        ),
        "out": attr.output(
            mandatory = True,
        ),
    },
)

$ bazel build //:error

You can also clone https://github.com/fmeum/cc_proto_library_transition_issue.

The command will generate the following error:

ERROR: file 'external/com_google_protobuf/_objs/protobuf_lite/int128.o' is generated by these conflicting actions:
Label: @com_google_protobuf//:protobuf_lite
RuleClass: cc_library rule
Configuration: 8d1a3355bd0201255e646e7ddf342ec528414ebbf2f1feab6e6b20aced50487e, 64b9564990ccaa73f2844f556c40131bd590d44ee9288aea2e3f3beb0c1a956b
Mnemonic: CppCompile
Action key: 4a432e1690a4da20c2fe249ae6554cf201d9792e4375c5a945c9962a8f2ec395, 9dc03c391082ba0e9a3e692ac5cc7257e5abab2a8de3eb5226db9bc4a4ba9f50
Progress message: Compiling src/google/protobuf/stubs/int128.cc
PrimaryInput: File:[/home/fhenneke/.cache/bazel/_bazel_fhenneke/3665225be4dbfed855cbc8b2bd45f83a/external/com_google_protobuf[source]]src/google/protobuf/stubs/int128.cc
PrimaryOutput: File:[[<execution_root>]bazel-out/k8-opt-exec-2B5CBBC6-ST-cbcaac683f1b/bin]external/com_google_protobuf/_objs/protobuf_lite/int128.o
Owner information: ConfiguredTargetKey{label=@com_google_protobuf//:protobuf_lite, config=BuildConfigurationValue.Key[8d1a3355bd0201255e646e7ddf342ec528414ebbf2f1feab6e6b20aced50487e]}, ConfiguredTargetKey{label=@com_google_protobuf//:protobuf_lite, config=BuildConfigurationValue.Key[64b9564990ccaa73f2844f556c40131bd590d44ee9288aea2e3f3beb0c1a956b]}
MandatoryInputs: are equal
Outputs: are equal
ERROR: com.google.devtools.build.lib.skyframe.ArtifactConflictFinder$ConflictException: com.google.devtools.build.lib.actions.MutableActionGraph$ActionConflictException: for external/com_google_protobuf/_objs/protobuf_lite/int128.o, previous action: action 'Compiling src/google/protobuf/stubs/int128.cc', attempted action: action 'Compiling src/google/protobuf/stubs/int128.cc'
INFO: Elapsed time: 0.121s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)

What operating system are you running Bazel on?

Ubuntu 20.10

What’s the output of bazel info release?

The issue reproduces with release 4.0.0 as well as master @ 7caa01fcb69b1b3d5c67476b100b13e82097227d, but not with release 3.7.2.

Using bazel-bisect.sh, I have identified the breaking commit as 7acf9ea3fea4850d21114d84fbc5b663d105d3c7, which enabled exec transitions on proto rules.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 20 (10 by maintainers)

Commits related to this issue

Most upvoted comments

@katre, @sdtwigg, and I are definitely discussing this further soon (we’ve scheduled time to talk about this). Thanks for the input.

I will take a look at your PR today. It is surprising because we had just (late last week) identified a separate issue with AspectFunction failing to ask for a proper, post-transition value but this seems like a different bug entirely.

On Sun, Aug 29, 2021 at 3:13 AM Fabian Meumertzheim < @.***> wrote:

I prepared #13915 https://github.com/bazelbuild/bazel/pull/13915, which resolves both this issue and the analogous one with --host_copt instead of --copt. It updates the transitionDirectoryNameFragment also taking into account that --host_copt becomes --copt under the exec transition.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bazelbuild/bazel/issues/13464#issuecomment-907742051, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHX76GMOTYW7X4N4YGILT3T7HMZ5ANCNFSM44UMY4LA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

There seems to be a broad class of issues related to action conflict detection when the owning ‘rule’ is an Aspect.

Unfortunately, the actual mechanism of this has been tricky to track down since the systems for both aspects and action conflict detection are a bit obscured.