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

Server crash when derived artifact in top-level package contains uplevel references #22362

Open
lberki opened this issue May 14, 2024 · 0 comments
Labels
team-Core Skyframe, bazel query, BEP, options parsing, bazelrc type: bug untriaged

Comments

@lberki
Copy link
Contributor

lberki commented May 14, 2024

Description of the bug:

Bazel crashes when one creates an artifact whose package-relative path contains .. in a rule whose package name is the empty string. The crash looks like this:

java.lang.RuntimeException: Unrecoverable error while evaluating node 'ConfiguredTargetKey{label=//:r, config=BuildConfigurationKey[f7b2890b4594e3d56423e2023135c0b84144d7515065abc76a75c81eeaac03f2]}' (requested by nodes 'ConfiguredTargetKey{label=//:r, config=BuildConfigurationKey[7d2b06aa3efa83a79f5d93af1e6af0dcb93e0bd2f5732e781f51429ef4ccded7]}')
        at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:557)
        at com.google.devtools.build.lib.concurrent.AbstractQueueVisitor$WrappedRunnable.run(AbstractQueueVisitor.java:426)
        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: net.starlark.java.eval.Starlark$UncheckedEvalException: IllegalArgumentException thrown during Starlark evaluation (//:r)
        at <starlark>.declare_file(<builtin>:0)
        at <starlark>._r_impl(/usr/local/google/home/lberki/bazel/t/r.bzl:2)
Caused by: java.lang.IllegalArgumentException: ../f
        at com.google.common.base.Preconditions.checkArgument(Preconditions.java:143)
        at com.google.devtools.build.lib.actions.ArtifactFactory.validatePath(ArtifactFactory.java:186)
        at com.google.devtools.build.lib.actions.ArtifactFactory.getDerivedArtifact(ArtifactFactory.java:228)
        at com.google.devtools.build.lib.analysis.CachingAnalysisEnvironment.getDerivedArtifact(CachingAnalysisEnvironment.java:282)
        at com.google.devtools.build.lib.analysis.RuleContext.getDerivedArtifact(RuleContext.java:789)
        at com.google.devtools.build.lib.analysis.RuleContext.getDerivedArtifact(RuleContext.java:773)
        at com.google.devtools.build.lib.analysis.starlark.StarlarkActionFactory.declareFile(StarlarkActionFactory.java:160)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source)
        at java.base/java.lang.reflect.Method.invoke(Unknown Source)
        at net.starlark.java.eval.MethodDescriptor.call(MethodDescriptor.java:178)
        at net.starlark.java.eval.BuiltinFunction.fastcall(BuiltinFunction.java:78)
        at net.starlark.java.eval.Starlark.fastcall(Starlark.java:807)
        at net.starlark.java.eval.Eval.evalCall(Eval.java:699)
        at net.starlark.java.eval.Eval.eval(Eval.java:514)
        at net.starlark.java.eval.Eval.execAssignment(Eval.java:121)
        at net.starlark.java.eval.Eval.exec(Eval.java:285)
        at net.starlark.java.eval.Eval.execStatements(Eval.java:82)
        at net.starlark.java.eval.Eval.execFunctionBody(Eval.java:66)
        at net.starlark.java.eval.StarlarkFunction.fastcall(StarlarkFunction.java:186)
        at net.starlark.java.eval.Starlark.fastcall(Starlark.java:807)
        at com.google.devtools.build.lib.analysis.starlark.StarlarkRuleConfiguredTargetUtil.evalRule(StarlarkRuleConfiguredTargetUtil.java:100)
        at com.google.devtools.build.lib.analysis.ConfiguredTargetFactory.createRule(ConfiguredTargetFactory.java:387)
        at com.google.devtools.build.lib.analysis.ConfiguredTargetFactory.createConfiguredTarget(ConfiguredTargetFactory.java:203)
        at com.google.devtools.build.lib.skyframe.SkyframeBuildView.createConfiguredTarget(SkyframeBuildView.java:1352)
        at com.google.devtools.build.lib.skyframe.ConfiguredTargetFunction.createConfiguredTarget(ConfiguredTargetFunction.java:389)
        at com.google.devtools.build.lib.skyframe.ConfiguredTargetFunction.compute(ConfiguredTargetFunction.java:313)
        at com.google.devtools.build.skyframe.AbstractParallelEvaluator$Evaluate.run(AbstractParallelEvaluator.java:468)
        at com.google.devtools.build.lib.concurrent.AbstractQueueVisitor$WrappedRunnable.run(AbstractQueueVisitor.java:426)
        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)

Which category does this issue belong to?

Core

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

cat > BUILD <<'EOF'
load("r.bzl", "r")

r(name = "r")
EOF

cat > r.bzl <<'EOF'
def _r_impl(ctx):
    f = ctx.actions.declare_file("../f")
    ctx.actions.write(f, "foo")
    return [DefaultInfo()]

r = rule(
    implementation = _r_impl,
)
EOF

touch MODULE.bazel

bazel build --nobuild //:r

Which operating system are you running Bazel on?

Linux

What is the output of bazel info release?

development version

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 ?

`bc16c579a155bec5289d9b929494d21a38212296`

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

@github-actions github-actions bot added the team-Core Skyframe, bazel query, BEP, options parsing, bazelrc label May 14, 2024
lberki added a commit to lberki/rules_perl that referenced this issue May 14, 2024
The reason it did not work was that the code assumed that the execpath
of any artifact can be passed to `ctx.actions.declare_file()`, but
that's not the case for artifacts not in the main repository when
sibling repository layout is in effect: their paths start with `../`
which would make them ascend above the package directory.

This also triggered a bug in Bazel
(bazelbuild/bazel#22362), but even if that bug
didn't exist, this would still not work.

Serendipitously, the principled fix for
`--experimental_sibling_repository_layout` is also a workaround for the
above bug. It adds two path segments to the package-relative path of the
.o file, akin to how c++ rules work.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
team-Core Skyframe, bazel query, BEP, options parsing, bazelrc type: bug untriaged
Projects
None yet
Development

No branches or pull requests

4 participants