Open rbeasley-avgo opened 1 month ago
If possible, please provide a repro since it is unclear to us how it could happen and a repro would help making progress.
If possible, please provide a repro since it is unclear to us how it could happen and a repro would help making progress.
Believe me, I'm trying. :) In the meantime, are there any other artifacts that could help w/ post-mortem debugging (e.g. --remote_grpc_log
, java.log
)? I'm happy to configure our builds to collect more information, sanitize it, and share here. If not, no worries; I'll do what I can to repeat the failure and home in on a repro case.
I suspect this might be the same as https://github.com/bazelbuild/bazel/issues/22387 because .d and .jdeps files are handled similarly by Bazel. Does setting --noexperimental_inmemory_jdeps_files
make the issue go away?
The --experimental_remote_grpc_log
would be useful. Feel free to sanitize file names, input arguments, etc, but please leave the digests intact (or rewrite them in a consistent manner) so they can be correlated across requests.
I suspect this might be the same as #22387 because .d and .jdeps files are handled similarly by Bazel. Does setting
--noexperimental_inmemory_jdeps_files
make the issue go away?
Yes, this goes away when using --noexperimental_inmemory_jdeps_files
. We've had no such failures since adopting that flag.
@rbeasley-avgo Can you provide either a repro, or an --experimental_remote_grpc_log
for a build exhibiting this failure? Otherwise it's going to be difficult to make progress on this.
@rbeasley-avgo Can you provide either a repro, or an
--experimental_remote_grpc_log
for a build exhibiting this failure? Otherwise it's going to be difficult to make progress on this.
Apologies for the radio silence. Was on PTO.
I haven't been able to generate a repro, so instead I'm just waiting for the west coast to wake up to review a change that removes the --noexperimental_inmemory_foo
flags from our builds. Once I have a few failures, I'll collect the gRPC logs, convert to plaintext (using bazelbuild/tools_remote), sanitize, and share with you.
Description of the bug:
Since upgrading to Bazel 7, we've encountered numerous sporadic build failures. Most are covered by other GitHub issues, but AFAICT nobody's filed one about .jdeps files.
I am going to experiment with
--noexperimental_inmemory_jdeps_files
.Which category does this issue belong to?
No response
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Unknown.
Which operating system are you running Bazel on?
Linux
What is the output of
bazel info release
?release 7.2.0-vmware
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.This is just Bazel 7.2.0 with a handful of patches for PRs that are either outstanding or have been rejected. None are related to scheduling, remote caching, etc.
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?
Any other information, logs, or outputs that you want to share?
Our RBE implementation is Buildfarm.
--noremote_upload_local_results
).experimental_inmemory_foo
flags?We're using the following options:
In failing builds w/ this syndrome,
java.log
contains backtraces resembling the following