-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Skymeld with --notrack_incremental_state
throws ArtifactPrefixConflictException
for TreeArtifact based cc_library
#22886
Comments
Should be fixed with 12aa54e |
@bazel-io flag |
@bazel-io fork 7.3.0 |
Can confirm the issue is fixed with that commit, thank you! Sorry to hijack an existing issue, but maybe you folks know what's up here. We've been getting a flaky bazel internal crash after upgrading to 7.2 from 6.4 that seems to be related to Skymeld and the same TreeArtifact-based cc library as in OP (*very slightly different setup, see below). The crash is unrelated to notrack_internal_state and conflict checking, but we haven't been able to get a consistent minimal repro so I haven't opened a new issue about it yet. Let me know if I should. We see the following crash:
The crash is inconsistent. If we repeat the exact same build straight afterwards, it doesn't occur again (some sort of inconsistent state / race?). The Do you have any tips to help aid in debugging or getting more information about this? Full generator setup: def _generate_api_files_impl(ctx):
# We need to put the C++ files in a folder names like a C++ file to trick Bazel to accepting these folders as
# sources and header when creating a C++ library.
srcs_tree = ctx.actions.declare_directory(ctx.attr.name + ".cc")
hdrs_tree = ctx.actions.declare_directory(ctx.attr.name + ".hh")
java_tree = ctx.actions.declare_directory(ctx.attr.name + "-java-srcs")
ctx.actions.run(
executable = ctx.executable.generator,
outputs = [srcs_tree, hdrs_tree, java_tree],
arguments = [srcs_tree.path, hdrs_tree.path, java_tree.path],
)
srcjar = ctx.actions.declare_file(ctx.attr.name + ".srcjar")
create_srcjar_rule(ctx, java_tree, srcjar, ctx.executable._build_zip)
return [DefaultInfo(files = depset([srcs_tree, hdrs_tree, srcjar]))]
generate_api_files = rule(
implementation = _generate_api_files_impl,
attrs = {
"generator": attr.label(executable = True, cfg = "exec"),
"_build_zip": attr.label(default = Label(BUILD_ZIP_TOOL), cfg = "exec", executable = True),
},
)
def generate_api(name, generator):
generate_api_files(name = name, generator = generator)
cc_library(
name = name + "-cc-lib",
srcs = [name],
hdrs = [name],
)
java_library(
name = name + "-java-lib",
srcs = [
":" + name,
],
) |
Description of the bug:
We have a source code generator that generates cpp & h files into a TreeArtifact. The tree artifact is then passed into a
cc_library
target.We recently upgraded from Bazel 6.4.0 to Bazel 7.2 and experience the following errors when
--notrack_incremental_state
is enabled (which we set on CI since our bazel servers are not kept across jobs)Note that this only happens when building both the cc_library target and an "independent" java_library target at the same time, defined in the same BUILD.bazel file. When building the cc_library target by itself, it does not error. When disabling skymeld with
--noexperimental_merged_skyframe_analysis_execution
it also does not error. When replacing the java_library with another random target (sh_library
/py_library
) it does not error.The java_library does not reference the cc_target at all, e.g.:
Which category does this issue belong to?
C++ Rules
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Setup a sample Bazel workspace with the following, to mimic a code generator creating .cc and .h files in tree artifacts
Try the following commands:
Note in particular that you must build the java_library target as well as the cc_library target at the same time. If you comment out the java_library target, or run the below command, it passes
Which operating system are you running Bazel on?
MacOS
What is the output of
bazel info release
?release 7.2.0
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse HEAD
?No response
If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
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
The text was updated successfully, but these errors were encountered: