Skip to content
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

Bazel crash on toolchain registration if toolchain declaration has incompatible dependency #23846

Open
alexander-shiryaev opened this issue Oct 2, 2024 · 2 comments
Labels
more data needed team-Configurability platforms, toolchains, cquery, select(), config transitions type: bug untriaged

Comments

@alexander-shiryaev
Copy link

Description of the bug:

Bazel crashes if, when registering a toolchain, in the chain of its dependencies
it encounters a target with target_compatible_with = ["@platforms//:incompatible"] set.

Starting local Bazel server and connecting to it...
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Loading: 
Loading: 0 packages loaded
Analyzing: target //:require_toolchain (1 packages loaded, 0 targets configured)
Analyzing: target //:require_toolchain (1 packages loaded, 0 targets configured)
[0 / 1] checking cached actions
FATAL: bazel crashed due to an internal error. Printing stack trace:
java.lang.RuntimeException: Unrecoverable error while evaluating node 'ConfiguredTargetKey{label=//:toolchain, config=BuildConfigurationKey[60f5dea2735e7a00db22cffca4067ff08ba19e8732f149961005afa9128121f4]}' (requested by nodes 'RegisteredToolchainsValue.Key{configurationKey: BuildConfigurationKey[60f5dea2735e7a00db22cffca4067ff08ba19e8732f149961005afa9128121f4]}')
    at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:550)
    at com.google.devtools.build.lib.concurrent.AbstractQueueVisitor$WrappedRunnable.run(AbstractQueueVisitor.java:414)
    at java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(Unknown Source)
    at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
    at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Unknown Source)
    at java.base/java.util.concurrent.ForkJoinPool.scan(Unknown Source)
    at java.base/java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
    at java.base/java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)
Caused by: java.lang.NullPointerException
    at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:903)
    at com.google.common.collect.ImmutableList$Builder.add(ImmutableList.java:815)
    at java.base/java.util.stream.ReduceOps$3ReducingSink.accept(Unknown Source)
    at java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)
    at java.base/java.util.AbstractList$RandomAccessSpliterator.forEachRemaining(Unknown Source)
    at java.base/java.util.stream.AbstractPipeline.copyInto(Unknown Source)
    at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
    at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(Unknown Source)
    at java.base/java.util.stream.AbstractPipeline.evaluate(Unknown Source)
    at java.base/java.util.stream.ReferencePipeline.collect(Unknown Source)
    at com.google.devtools.build.lib.rules.platform.Toolchain.create(Toolchain.java:57)
    at com.google.devtools.build.lib.rules.platform.Toolchain.create(Toolchain.java:38)
    at com.google.devtools.build.lib.analysis.ConfiguredTargetFactory.createRule(ConfiguredTargetFactory.java:408)
    at com.google.devtools.build.lib.analysis.ConfiguredTargetFactory.createConfiguredTarget(ConfiguredTargetFactory.java:194)
    at com.google.devtools.build.lib.skyframe.SkyframeBuildView.createConfiguredTarget(SkyframeBuildView.java:1312)
    at com.google.devtools.build.lib.skyframe.ConfiguredTargetFunction.createConfiguredTarget(ConfiguredTargetFunction.java:385)
    at com.google.devtools.build.lib.skyframe.ConfiguredTargetFunction.compute(ConfiguredTargetFunction.java:312)
    at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:461)
    ... 7 more

Which category does this issue belong to?

Configurability, Core

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

# https://github.com/alexander-shiryaev/bazel_issue/tree/main/bug/bazel_crash_on_error_during_toolchain_registration
bazel build :require_toolchain

Which operating system are you running Bazel on?

does not matter

What is the output of bazel info release?

release 7.1.0

If bazel info release returns development 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.

Any other information, logs, or outputs that you want to share?

Code for the example: https://github.com/alexander-shiryaev/bazel_issue/tree/main/bug/bazel_crash_on_error_during_toolchain_registration

@github-actions github-actions bot added team-Configurability platforms, toolchains, cquery, select(), config transitions team-Core Skyframe, bazel query, BEP, options parsing, bazelrc labels Oct 2, 2024
@haxorz haxorz removed the team-Core Skyframe, bazel query, BEP, options parsing, bazelrc label Oct 22, 2024
@katre
Copy link
Member

katre commented Dec 20, 2024

I think there's a real bug here, but I can't cause it to happen with your reproduction using Bazel built from head (specifically, we've been steadily removing support for config_common.FeatureFlagInfo).

Can you reproduce this without a flag, or with a label_flag, instead? When I try I get reasonable-looking error messages.

@alexander-shiryaev
Copy link
Author

alexander-shiryaev commented Dec 21, 2024

@katre The whole point here is that we use config_common.FeatureFlagInfo + config_setting to implement custom conditions for the select operator. Even if the bug is reproduced somehow else, it is of little use to us.

specifically, we've been steadily removing support for config_common.FeatureFlagInfo

This is extremely worrying news for us, since a significant part of our core build rules library is built on creating custom conditions for the select operator. Will there be any alternative to implement this scenario if you plan to get rid of config_common.FeatureFlagInfo?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
more data needed team-Configurability platforms, toolchains, cquery, select(), config transitions type: bug untriaged
Projects
None yet
Development

No branches or pull requests

6 participants