Where is the error log?

[maths644311798]

Description of the bug:

When I use bazel build //... -c opt --jobs 8 --sandbox_debug to compile a repository, it just says "bazel FAILED: Build did NOT complete successfully". But there are no more error messages. Where can I find the log that locates the error?

Which category does this issue belong to?

Configurability

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

No response

Which operating system are you running Bazel on?

No response

What is the output of bazel info release?

No response

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 response

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

No response

[maths644311798]

I have added these commands '--verbose_failures', '--jobs', '8', '-c', 'opt', '--config=avx'.
The last output in std I see is

INFO: From Compiling xla/mlir_hlo/mhlo/transforms/legalize_to_linalg/legalize_to_linalg.cc:
In file included from external/xla/xla/mlir_hlo/mhlo/transforms/legalize_to_linalg/legalize_to_linalg.cc:30:
bazel-out/k8-opt/bin/external/xla/xla/mlir_hlo/_virtual_includes/map_mhlo_to_scalar_op/mhlo/transforms/map_mhlo_to_scalar_op.h: In function 'mlir::Value mlir::mhlo::impl::mapMhloOpToStdScalarOp(mlir::Location, llvm::ArrayRef<mlir::Type>, llvm::ArrayRef<mlir::Type>, typename MhloOpTy::Adaptor, mlir::OpBuilder*) [with MhloOpTy = mlir::mhlo::DotOp; typename MhloOpTy::Adaptor = mlir::mhlo::DotOpAdaptor]':
bazel-out/k8-opt/bin/external/xla/xla/mlir_hlo/_virtual_includes/map_mhlo_to_scalar_op/mhlo/transforms/map_mhlo_to_scalar_op.h:844:15: warning: possibly dangling reference to a temporary [-Wdangling-reference]
  844 |   const auto& lhs = adaptor.getOperands()[0];
      |               ^~~
bazel-out/k8-opt/bin/external/xla/xla/mlir_hlo/_virtual_includes/map_mhlo_to_scalar_op/mhlo/transforms/map_mhlo_to_scalar_op.h:844:44: note: the temporary was destroyed at the end of the full expression 'adaptor.mlir::mhlo::DotOpAdaptor::mlir::mhlo::DotOpGenericAdaptor<mlir::ValueRange>.mlir::mhlo::DotOpGenericAdaptor<mlir::ValueRange>::getOperands().mlir::ValueRange::llvm::detail::indexed_accessor_range_base<mlir::ValueRange, llvm::PointerUnion<const mlir::Value*, mlir::OpOperand*, mlir::detail::OpResultImpl*>, mlir::Value, mlir::Value, mlir::Value>.llvm::detail::indexed_accessor_range_base<mlir::ValueRange, llvm::PointerUnion<const mlir::Value*, mlir::OpOperand*, mlir::detail::OpResultImpl*>, mlir::Value, mlir::Value, mlir::Value>::operator[](0)'
  844 |   const auto& lhs = adaptor.getOperands()[0];
      |                                            ^
bazel-out/k8-opt/bin/external/xla/xla/mlir_hlo/_virtual_includes/map_mhlo_to_scalar_op/mhlo/transforms/map_mhlo_to_scalar_op.h:845:15: warning: possibly dangling reference to a temporary [-Wdangling-reference]
  845 |   const auto& rhs = adaptor.getOperands()[1];
      |               ^~~
bazel-out/k8-opt/bin/external/xla/xla/mlir_hlo/_virtual_includes/map_mhlo_to_scalar_op/mhlo/transforms/map_mhlo_to_scalar_op.h:845:44: note: the temporary was destroyed at the end of the full expression 'adaptor.mlir::mhlo::DotOpAdaptor::mlir::mhlo::DotOpGenericAdaptor<mlir::ValueRange>.mlir::mhlo::DotOpGenericAdaptor<mlir::ValueRange>::getOperands().mlir::ValueRange::llvm::detail::indexed_accessor_range_base<mlir::ValueRange, llvm::PointerUnion<const mlir::Value*, mlir::OpOperand*, mlir::detail::OpResultImpl*>, mlir::Value, mlir::Value, mlir::Value>.llvm::detail::indexed_accessor_range_base<mlir::ValueRange, llvm::PointerUnion<const mlir::Value*, mlir::OpOperand*, mlir::detail::OpResultImpl*>, mlir::Value, mlir::Value, mlir::Value>::operator[](1)'
  845 |   const auto& rhs = adaptor.getOperands()[1];
      |                                            ^
bazel-out/k8-opt/bin/external/xla/xla/mlir_hlo/_virtual_includes/map_mhlo_to_scalar_op/mhlo/transforms/map_mhlo_to_scalar_op.h:846:15: warning: possibly dangling reference to a temporary [-Wdangling-reference]
  846 |   const auto& result = adaptor.getOperands()[2];
      |               ^~~~~~
bazel-out/k8-opt/bin/external/xla/xla/mlir_hlo/_virtual_includes/map_mhlo_to_scalar_op/mhlo/transforms/map_mhlo_to_scalar_op.h:846:47: note: the temporary was destroyed at the end of the full expression 'adaptor.mlir::mhlo::DotOpAdaptor::mlir::mhlo::DotOpGenericAdaptor<mlir::ValueRange>.mlir::mhlo::DotOpGenericAdaptor<mlir::ValueRange>::getOperands().mlir::ValueRange::llvm::detail::indexed_accessor_range_base<mlir::ValueRange, llvm::PointerUnion<const mlir::Value*, mlir::OpOperand*, mlir::detail::OpResultImpl*>, mlir::Value, mlir::Value, mlir::Value>.llvm::detail::indexed_accessor_range_base<mlir::ValueRange, llvm::PointerUnion<const mlir::Value*, mlir::OpOperand*, mlir::detail::OpResultImpl*>, mlir::Value, mlir::Value, mlir::Value>::operator[](2)'
  846 |   const auto& result = adaptor.getOperands()[2];
      |                                               ^
INFO: Elapsed time: 2905.332s, Critical Path: 743.99s
INFO: 5575 processes: 283 internal, 5292 processwrapper-sandbox.
FAILED: Build did NOT complete successfully

I did not see any detailed error information.

[tjgq]

Can you share the Bazel output in its entirety? (Attach a file if it's too big for a GitHub comment)

[maths644311798]

command.log

Do I need to follow the information in this file called "command.log" to debug?

[tjgq]

The command.log link points to this issue.

[maths644311798]

The file is uploaded now. My key question is: how can I gather the error information if I build via bazel.

command.log

Do I need to follow the information in this file called "command.log" to debug?

[tjgq]

The command.log is a copy of the output Bazel prints to the terminal.

There are several errors in your build; here's the first one of them:

�[1A�[K�[31m�[1mERROR: �[0m/root/.cache/bazel/_bazel_root/68fadb4cca283e59dfc7b3a1fcd5f987/external/com_github_libsodium/BUILD.bazel:17:8: Executing genrule @com_github_libsodium//:gen_sh [for tool] failed: (Exit 127): bash failed: error executing command (from target @com_github_libsodium//:gen_sh) 
  (cd /root/.cache/bazel/_bazel_root/68fadb4cca283e59dfc7b3a1fcd5f987/sandbox/processwrapper-sandbox/6/execroot/spulib && \
  exec env - \
    LD_LIBRARY_PATH=/usr/local/gcc-14.1.0/lib64:/usr/local/gcc-14.1.0/lib/gcc/x86_64-linux-gnu/14.2.0/: \
    PATH=/root/.cache/bazelisk/downloads/sha256/a40ac69263440761199fcb8da47ad4e3f328cbe79ffbf4ecc14e5ba252857307/bin:/root/miniconda3/bin:/root/miniconda3/condabin:/usr/local/gcc-14.1.0/bin:/root/miniconda3/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
  /bin/bash -c 'source external/bazel_tools/tools/genrule/genrule-setup.sh; 
cat > bazel-out/k8-opt-exec-50AE0418/bin/external/com_github_libsodium/gen.sh <<"EOF"
#!/bin/sh
sed -e '\''s/@VERSION@/1.0.18/g'\''     -e '\''s/@SODIUM_LIBRARY_VERSION_MAJOR@/11/g'\''     -e '\''s/@SODIUM_LIBRARY_VERSION_MINOR@/0/g'\''     -e '\''s/@SODIUM_LIBRARY_MINIMAL_DEF@//g'\''
EOF')
# Configuration: 809d0f43dc0549d043b3dc904cb1bb786c6f1cac2a3cf70e60273d1a1c68bc67
# Execution platform: @local_execution_config_platform//:platform

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
/bin/bash: line 1: $'\r': command not found

The /bin/bash: line 1: $'\r': command not found seems to be common to all errors. This usually indicates that the script contains a Windows-style line terminator (\r\n) instead of Unix-style (\n). But the scripts in question are generated by Bazel, not user-authored, so I'm not quite sure what's going on.

[tjgq]

Which Bazel version are you running?

Can you reproduce the issue by building a trivial genrule:

genrule(
  name = "gen",
  outs = ["out.txt"],
  cmd = "touch $@",
)

[maths644311798]

The Bazel version is 6.5.0. And this issue can not be reproduced via

genrule(
  name = "gen",
  outs = ["out.txt"],
  cmd = "touch $@",
)

It seems that only some special libraries like libsodium can produce this issue.

[tjgq]

Can you check whether the file bazel-WORKSPACE/external/bazel_tools/tools/genrule/genrule-setup.sh (where WORKSPACE is the workspace name of your failing build) has Unix or Windows line terminators?

[maths644311798]

I have checked genrule-setup.sh. Its line terminators are all \n, that is, using unix style. And I have debuged following command.log and all bugs are solved now.
To solve the file style problem, I just vim the files and set ff=unix in vim.
This issue can be closed. If you want to analyze more about the genrule problem, I can continue.