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 + MSVC C++ = missing dependency declarations [culprit #5136] #5640

Closed
derekmauro opened this issue Jul 19, 2018 · 37 comments
Closed

Bazel + MSVC C++ = missing dependency declarations [culprit #5136] #5640

derekmauro opened this issue Jul 19, 2018 · 37 comments
Labels
area-Windows Windows-specific issues and feature requests P3 We're not considering working on this, but happy to review a PR. (No assignee) platform: windows stale Issues or PRs that are stale (no activity for 30 days) team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website type: bug

Comments

@derekmauro
Copy link

derekmauro commented Jul 19, 2018

Description of the problem / feature request:

We are getting a spurious this rule is missing dependency declarations for the following files included by ... when using MSVC to build on Windows. I say it is spurious because the same command works correctly on Linux and OSX, and I've verified the BUILD rule is correct.

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

On Windows + MSVC:

git clone https://github.com/abseil/abseil-cpp.git
bazel test --define absl=1 absl/...

The --define absl=1 part makes Google Test use Abseil. So Abseil tests uses Google Test, which in turn uses the Abseil libraries. I'm not sure if the circular project dependency has anything to do with this. Everything works as expected without --define absl=1.

Output on my machine:

PS C:\Users\dmauro\abseil-cpp> bazel --bazelrc=/dev/null test --define absl=1 absl/...
Loading:
Loading: 0 packages loaded
INFO: Build options have changed, discarding analysis cache.
Analyzing: 157 targets (16 packages loaded)
INFO: Analysed 157 targets (34 packages loaded).
INFO: Found 55 targets and 102 test targets...
[0 / 11] [-----] Creating source manifest for //absl/strings:ascii_test
[10 / 33] Compiling external/com_google_absl/absl/strings/charconv.cc; 1s local ... (4 actions running)
[15 / 33] Compiling external/com_google_absl/absl/strings/substitute.cc; 1s local ... (4 actions, 3 running)
[19 / 33] Compiling external/com_google_absl/absl/strings/str_cat.cc; 1s local ... (4 actions, 3 running)
[24 / 38] Compiling external/com_google_absl/absl/strings/str_replace.cc; 1s local ... (3 actions running)
[36 / 55] Compiling external/com_google_absl/absl/debugging/failure_signal_handler.cc; 0s local ... (4 actions running)
[39 / 58] Compiling external/com_google_absl/absl/debugging/failure_signal_handler.cc; 1s local ... (4 actions running)
[45 / 66] Compiling absl/base/internal/spinlock.cc; 1s local ... (4 actions, 3 running)
[54 / 78] Compiling external/com_google_absl/absl/base/internal/low_level_alloc.cc; 1s local ... (4 actions running)
[55 / 79] Compiling external/com_google_googletest/googletest/src/gtest-death-test.cc; 2s local ... (4 actions running)
[60 / 84] Compiling external/com_google_googletest/googletest/src/gtest.cc; 2s local ... (3 actions running)
[64 / 89] Compiling external/com_google_googletest/googletest/src/gtest-printers.cc; 2s local ... (4 actions running)
[73 / 98] Compiling absl/strings/str_replace.cc; 1s local ... (4 actions running)
[86 / 113] Compiling external/com_google_absl/absl/base/internal/spinlock.cc; 1s local ... (4 actions running)
ERROR: C:/users/dmauro/abseil-cpp/absl/strings/BUILD.bazel:148:1: undeclared inclusion(s) in rule '//absl/strings:ascii_
test':
this rule is missing dependency declarations for the following files included by 'absl/strings/ascii_test.cc':
  'absl/types/optional.h'
  'absl/utility/utility.h'
  'absl/types/bad_optional_access.h'
  'absl/types/variant.h'
  'absl/types/internal/variant.h'
  'absl/types/bad_variant_access.h'
INFO: Elapsed time: 29.078s, Critical Path: 4.50s
INFO: 71 processes: 71 local.
FAILED: Build did NOT complete successfully

It's interesting that I see both Compiling absl/base/internal/spinlock.cc; and external/com_google_absl/absl/base/internal/low_level_alloc.cc; (note the external/com_google_absl prefix). It is as if Bazel doesn't understand that the root WORKSPACE, named com_google_absl, isn't the same Abseil that Google Test depends on, even though it depends on Abseil under the name com_google_absl. A Linux build never shows the external/com_google_absl in the output.

What operating system are you running Bazel on?

Windows 2008 R2 on GCP. I also tried it on a Kokoro instance (not sure of the Windows version of that) and got the same result.

What's the output of bazel info release?

PS C:\Users\dmauro\abseil-cpp> bazel version
Build label: 0.15.0
Build target: bazel-out/x64_windows-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Tue Jun 26 12:09:42 2018 (1530014982)
Build timestamp: 1530014982
Build timestamp as int: 1530014982
PS C:\Users\dmauro\abseil-cpp> bazel info release
release 0.15.0

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

PS C:\Users\dmauro\abseil-cpp> git remote get-url origin ; git rev-parse master ; git rev-parse HEAD
https://github.com/abseil/abseil-cpp.git
2c5af55ed34850d8b7dd46177c8ca53fdfda920e
2c5af55ed34850d8b7dd46177c8ca53fdfda920e

Have you found anything relevant by searching the web?

#5087 is possibly the same issue, but I'm not sure. That issue refers to remote workers.

@rongjiecomputer
Copy link
Contributor

I can reproduce the issue with Bazel from master branch and VS 2017 15.7 and Clang on Windows (master).

@derekmauro I have some idea, but I will need your help to verify it. Can you do the following on Linux machine with GCC/Clang?

  1. Run bazel test --define absl=1 //absl/base:throw_delegate_test
  2. Modify throw_delegate_test.cc.
  3. Run bazel test --define absl=1 //absl/base:throw_delegate_test -s
  4. Paste the console output here (I am only interested in the subcommand when compiling throw_delegate_test.cc).

@derekmauro
Copy link
Author

Output from step 3:

$ bazel test --define absl=1 //absl/base:throw_delegate_test -s
INFO: Analysed target //absl/base:throw_delegate_test (0 packages loaded).
INFO: Found 1 test target...
SUBCOMMAND: # //absl/base:throw_delegate_test [action 'Compiling absl/base/throw_delegate_test.cc']
(cd /home/dmauro/.cache/bazel/_bazel_dmauro/e240e8f4f46ded87fd03013f5525686b/execroot/com_google_absl && \
  exec env - \
    PATH=/home/dmauro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
    PWD=/proc/self/cwd \
  /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -B/usr/bin -B/usr/bin -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer '-std=c++0x' -MD -MF bazel-out/k8-fastbuild/bin/absl/base/_objs/throw_delegate_test/absl/base/throw_delegate_test.pic.d '-frandom-seed=bazel-out/k8-fastbuild/bin/absl/base/_objs/throw_delegate_test/absl/base/throw_delegate_test.pic.o' -fPIC -D__CLANG_SUPPORT_DYN_ANNOTATION__ '-DGTEST_HAS_ABSL=1' -iquote . -iquote bazel-out/k8-fastbuild/genfiles -iquote external/bazel_tools -iquote bazel-out/k8-fastbuild/genfiles/external/bazel_tools -iquote external/com_google_googletest -iquote bazel-out/k8-fastbuild/genfiles/external/com_google_googletest -iquote external/com_google_absl -iquote bazel-out/k8-fastbuild/genfiles/external/com_google_absl -isystem external/com_google_googletest/googlemock -isystem bazel-out/k8-fastbuild/genfiles/external/com_google_googletest/googlemock -isystem bazel-out/k8-fastbuild/bin/external/com_google_googletest/googlemock -isystem external/com_google_googletest/googlemock/include -isystem bazel-out/k8-fastbuild/genfiles/external/com_google_googletest/googlemock/include -isystem bazel-out/k8-fastbuild/bin/external/com_google_googletest/googlemock/include -isystem external/com_google_googletest/googletest -isystem bazel-out/k8-fastbuild/genfiles/external/com_google_googletest/googletest -isystem bazel-out/k8-fastbuild/bin/external/com_google_googletest/googletest -isystem external/com_google_googletest/googletest/include -isystem bazel-out/k8-fastbuild/genfiles/external/com_google_googletest/googletest/include -isystem bazel-out/k8-fastbuild/bin/external/com_google_googletest/googletest/include -Wall -Wextra -Wcast-qual -Wconversion-null -Wmissing-declarations -Woverlength-strings -Wpointer-arith -Wunused-local-typedefs -Wunused-result -Wvarargs -Wvla -Wwrite-strings -Wno-sign-compare -Wno-conversion-null -Wno-missing-declarations -Wno-sign-compare -Wno-unused-function -Wno-unused-parameter -Wno-unused-private-field -fexceptions -fno-canonical-system-headers -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c absl/base/throw_delegate_test.cc -o bazel-out/k8-fastbuild/bin/absl/base/_objs/throw_delegate_test/absl/base/throw_delegate_test.pic.o)
SUBCOMMAND: # //absl/base:throw_delegate_test [action 'Linking absl/base/throw_delegate_test']
(cd /home/dmauro/.cache/bazel/_bazel_dmauro/e240e8f4f46ded87fd03013f5525686b/execroot/com_google_absl && \
  exec env - \
    PATH=/home/dmauro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
    PWD=/proc/self/cwd \
  /usr/bin/gcc -o bazel-out/k8-fastbuild/bin/absl/base/throw_delegate_test '-Wl,-rpath,$ORIGIN/../../_solib_k8/' -Lbazel-out/k8-fastbuild/bin/_solib_k8 -pthread '-fuse-ld=gold' -Wl,-no-as-needed -Wl,-z,relro,-z,now -B/usr/bin -B/usr/bin -pass-exit-codes -Wl,-S -Wl,@bazel-out/k8-fastbuild/bin/absl/base/throw_delegate_test-2.params)
SUBCOMMAND: # //absl/base:throw_delegate_test [action 'Testing //absl/base:throw_delegate_test']
(cd /home/dmauro/.cache/bazel/_bazel_dmauro/e240e8f4f46ded87fd03013f5525686b/execroot/com_google_absl && \
  exec env - \
    JAVA_RUNFILES=bazel-out/k8-fastbuild/bin/absl/base/throw_delegate_test.runfiles \
    PATH=/home/dmauro/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
    PYTHON_RUNFILES=bazel-out/k8-fastbuild/bin/absl/base/throw_delegate_test.runfiles \
    RUNFILES_DIR=bazel-out/k8-fastbuild/bin/absl/base/throw_delegate_test.runfiles \
    RUN_UNDER_RUNFILES=1 \
    TEST_BINARY=absl/base/throw_delegate_test \
    TEST_INFRASTRUCTURE_FAILURE_FILE=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.infrastructure_failure \
    TEST_LOGSPLITTER_OUTPUT_FILE=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.raw_splitlogs/test.splitlogs \
    TEST_PREMATURE_EXIT_FILE=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.exited_prematurely \
    TEST_SIZE=medium \
    TEST_SRCDIR=bazel-out/k8-fastbuild/bin/absl/base/throw_delegate_test.runfiles \
    TEST_TARGET=//absl/base:throw_delegate_test \
    TEST_TIMEOUT=300 \
    TEST_TMPDIR=_tmp/5cb1cd4ee5a296cc53b755bf19211d99 \
    TEST_UNDECLARED_OUTPUTS_ANNOTATIONS=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.outputs_manifest/ANNOTATIONS \
    TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.outputs_manifest \
    TEST_UNDECLARED_OUTPUTS_DIR=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.outputs \
    TEST_UNDECLARED_OUTPUTS_MANIFEST=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.outputs_manifest/MANIFEST \
    TEST_UNDECLARED_OUTPUTS_ZIP=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.outputs/outputs.zip \
    TEST_UNUSED_RUNFILES_LOG_FILE=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.unused_runfiles_log \
    TEST_WARNINGS_OUTPUT_FILE=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.warnings \
    TEST_WORKSPACE=com_google_absl \
    TZ=UTC \
    XML_OUTPUT_FILE=bazel-out/k8-fastbuild/testlogs/absl/base/throw_delegate_test/test.xml \
  external/bazel_tools/tools/test/test-setup.sh absl/base/throw_delegate_test)
Target //absl/base:throw_delegate_test up-to-date:
  bazel-bin/absl/base/throw_delegate_test
INFO: Elapsed time: 1.118s, Critical Path: 0.91s
INFO: 3 processes: 3 linux-sandbox.
INFO: Build completed successfully, 4 total actions
//absl/base:throw_delegate_test                                          PASSED in 0.1s

Executed 1 out of 1 test: 1 test passes.
There were tests whose specified size is too big. Use the --test_verbose_timeoutINFO: Build completed successfully, 4 total actions

@rongjiecomputer
Copy link
Contributor

Thanks for the console output. It disprove my guess that the include flags -I might be different for GCC/Clang and MSVC. Bazel always add include path . before external/com_google_absl regardless of compilers.

From what I can see in Bazel's java code, Bazel handles MSVC's /showIncludes output and GCC/Clang's -MD ouput in different code path (see 0), but the validation seems to be done in the same function (see 1). Java code is not my expertise, so I think I will stop here.

@rongjiecomputer
Copy link
Contributor

@meteorcloudy @mhlopko Can you take a look?

@meteorcloudy
Copy link
Member

@rongjiecomputer Thanks for the help, I'll take it from here.

@meteorcloudy meteorcloudy self-assigned this Aug 8, 2018
@meteorcloudy
Copy link
Member

@derekmauro I've debugged on this and found the root cause. Let me explain how this issue happened on Windows and not on Linux.

  • First, the google test framework depends on a certain version of absel. See
    https://github.com/google/googletest/blob/master/WORKSPACE. Bazel downloads it as an external repository, that's why external/com_google_absl/absl/... exists. It will be compiled when enabling define absl=1. This is also true on Linux.
$ bazel query 'somepath(//absl/strings:ascii_test, @com_google_absl//absl/types:optional)'
//absl/strings:ascii_test
@com_google_googletest//:gtest_main
@com_google_googletest//:gtest
@com_google_absl//absl/types:optional
  • When compiling absl/strings/ascii_test.cc, two include directories will be added - . and external/com_google_absl. Both directories contains absl/types/optional.h and other header files. The first one will be detected by the compiler, but only the second one is declared as dependency of the test. The dependency check thus failed.
  • It didn't happen on Linux because sandbox is enabled by default. Since absl/types/optional.h is not declared as dependency, the compiler won't see it. If you build with --spawn_strategy=standalone, you'll get the same error as Windows.

@dslomov Is there anyway to override @com_google_absl in googletest to point to the local absl repository ?

@dslomov
Copy link
Contributor

dslomov commented Aug 8, 2018

Not right now, but there will be once experimental_enable_repo_mapping is fully finished and #3115 is fixed.

@meteorcloudy
Copy link
Member

@dslomov Thanks! Then I'll assign this to you.

@meteorcloudy meteorcloudy assigned dslomov and unassigned meteorcloudy Aug 13, 2018
@meteorcloudy
Copy link
Member

FYI @laszlocsomor, this is the similar bug you encountered recently.

@meteorcloudy
Copy link
Member

/cc @mhlopko This issue happens when you have the same header file under /I. and /Iextenral/<repository_name>, I guess we don't have any other way to avoid the conflict except enabling sandbox? (which only available on Unix).

@laszlocsomor
Copy link
Contributor

@mhlopko, @meteorcloudy : I think the culprit is that every action runs in the same execution root. I believe the single execution root is the reason the compilation action has /Iexternal/foo -- to enable compiling cc_* rules even when they are in external repos.

@laszlocsomor
Copy link
Contributor

laszlocsomor commented Aug 29, 2018

And I believe we could solve this problem if all build actions corresponding to rules in external repos would use <execroot>/external/<reponame> as their execution root, and only the main repo's build actions would use <execroot>.

@meteorcloudy
Copy link
Member

@laszlocsomor What if you have a cc_library lib.cc in your main repo, which depends on repo_x and includes foo/bar/x.h under <execroot>/external/repo_x. And you happen to have foo/bar/x.h under your source tree. We'll still have the same problem during compiling lib.cc, because /I. and /Iexternal/repo_x (relative to <execroot>) are both passed to the compiler.

@rongjiecomputer
Copy link
Contributor

If /I. is added only after all the /Iexternal/repo, it should solve the issue Abseil is having, but I afraid that other issues might arise.

@meteorcloudy
Copy link
Member

@rongjiecomputer Yes, that would be wrong if the actual file you want to include is in your main repo instead of external repo. I think the only way to make it right is sandbox, this way it can keep the compiler from accidentally discovering undeclared include files. (although there could still be header file conflicts between declared dependencies).

@laszlocsomor
Copy link
Contributor

laszlocsomor commented Aug 29, 2018

@meteorcloudy : Indeed you're right.

I also forgot to consider @repo//bar/b.cc may #include "bar/b.h", but @repo//bar:b may depend on rules in other external repos (e.g. @oper//qux:c), so even if the effective execution root for compiling @repo//bar:b were <execroot>/external/repo, this directory would have to contain a symlink <execroot>/external/repo/external/oper pointing to <execroot>/external/oper.

Update: fixed repo paths.

@laszlocsomor
Copy link
Contributor

laszlocsomor commented Aug 29, 2018

Correction: the symlink would have to be <execroot>/external/repo/external/oper, and point to <execroot>/external/oper. (Fixed in previous post.)

@laszlocsomor
Copy link
Contributor

@meteorcloudy :

although there could still be header file conflicts between declared dependencies

Right, for example when a library depends on both //foo:x and @repo//foo:x and those both have foo/x.h in hdrs.

@laszlocsomor
Copy link
Contributor

I think the include scanner could catch this error and suggest a fix ("Did you mean to include external/repo/foo/x.h instead of foo/x.h?"). Bazel knows the allowed set of included headers, so the include scanner could detect if an illegally included header file exists under one of the external repos.

@meteorcloudy
Copy link
Member

the include scanner could catch this error and suggest a fix ("Did you mean to include external/repo/foo/x.h instead of foo/x.h?")

I agree.

@laszlocsomor
Copy link
Contributor

laszlocsomor commented Aug 29, 2018

After in-person discussion with @mhlopko and @meteorcloudy, it became clear that including files via "external/reponame" is in fact the wrong approach.

When a header file (lib/x.h) includes another file from its own package (lib/y.h), the inclusion path will be repo-relative. But if these headers are in an external repo (@foo) and a file in the main repo (main.cc) includes the first header as external/foo/lib/x.h, then the header's own inclusion path will now be wrong because it is missing the external/foo/ part.

The author of lib/x.h of course cannot foresee what external repo names their code will be imported under, so they cannot write future-proof include paths under external/. That's why repo-relative include paths must remain supported even for headers included from external repos, and my idea of including via external/foo/ is misguided.

laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Aug 29, 2018
Avoid include collision inside the Bazel source
tree when a rule depends on
@bazel_tools//tools/cpp/runfiles and includes
"tools/cpp/runfiles/runfiles.h", but they end up
getting "tools/cpp/runfiles/runfiles.h" from the
main repo.

Change-Id: Ic0fa23045b25cf9b1987780f9e752a54fa32be45
Details: bazelbuild#5640 (comment)
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Aug 29, 2018
Avoid include collision inside the Bazel source
tree when a rule depends on
@bazel_tools//tools/cpp/runfiles and includes
"tools/cpp/runfiles/runfiles.h", but they end up
getting "tools/cpp/runfiles/runfiles.h" from the
main repo.

Change-Id: Ic0fa23045b25cf9b1987780f9e752a54fa32be45
Details: bazelbuild#5640 (comment)
bazel-io pushed a commit that referenced this issue Aug 30, 2018
Avoid include collision inside the Bazel source
tree when a rule depends on
@bazel_tools//tools/cpp/runfiles and includes
"tools/cpp/runfiles/runfiles.h", but they end up
getting "tools/cpp/runfiles/runfiles.h" from the
main repo.

Change-Id: Ic0fa23045b25cf9b1987780f9e752a54fa32be45
Details: #5640 (comment)

Closes #6023.

Change-Id: Ic0fa23045b25cf9b1987780f9e752a54fa32be45
PiperOrigin-RevId: 210878008
@gennadiycivil
Copy link

gennadiycivil commented Nov 9, 2018 via email

@rongjiecomputer
Copy link
Contributor

rongjiecomputer commented Nov 9, 2018

Inspired by @laszlocsomor's solution:

In a WORKSPACE, specify Abseil and GoogleTest as [new_]local_repository or [new_]http_archive (so neither Abseil nor GoogleTest is the main repo __main__) (*), then run bazel test --define absl=1 @com_google_absl//absl/base/.... All tests pass.

I believe (*) is how most Bazel users consume Abseil and GoogleTest (main repo is user's own code). This solution should enable Abseil team to continue their work without breaking existing Abseil and GoogleTest users.

@gennadiycivil
Copy link

gennadiycivil commented Nov 13, 2018 via email

rongjiecomputer added a commit to rongjiecomputer/bazel-issue that referenced this issue Nov 14, 2018
@rongjiecomputer
Copy link
Contributor

rongjiecomputer commented Nov 14, 2018

Sure thing! See https://github.com/rongjiecomputer/bazel-issue/tree/master/abseil

EDIT: fix cd command.

git clone --depth 1 https://github.com/rongjiecomputer/bazel-issue
cd bazel-issue/abseil
bazel test -c opt --define absl=1 @com_google_absl//absl/...

@laszlocsomor laszlocsomor added area-Windows Windows-specific issues and feature requests type: bug P3 We're not considering working on this, but happy to review a PR. (No assignee) and removed team-Rules-CPP Issues for C++ rules labels Apr 8, 2019
@laszlocsomor
Copy link
Contributor

Sandboxing on Windows would solve this problem.

@laszlocsomor
Copy link
Contributor

Lack of sandboxing is the culprit of this bug, and @rongjiecomputer is working on #5136 to address that.

Closing this in favor of #5136.

@laszlocsomor
Copy link
Contributor

Actually, let's keep this open until sandoxing is done.

@laszlocsomor laszlocsomor reopened this Jul 8, 2019
@laszlocsomor laszlocsomor changed the title Bazel + MSVC C++ = missing dependency declarations Bazel + MSVC C++ = missing dependency declarations [culprit #5136] Jul 8, 2019
nareddyt added a commit to nareddyt/oss-fuzz that referenced this issue Mar 9, 2020
[Example failure](https://oss-fuzz-build-logs.storage.googleapis.com/log-8eabbac0-bb8f-4f90-a840-f23efe427e0e.txt)

This only occurs on the fuzzers for some reason, not on Travis CI. Error is similar to bazelbuild/bazel#5640.

Change spawn strategy to `sandboxed` to work around this. Not sure why it was `local` to begin with (other than a slight performance improvement).

Tested locally to ensure this spawn strategy will work.

```
python infra/helper.py build_fuzzers --sanitizer address --engine libfuzzer --architecture x86_64 esp-v2
```

Signed-off-by: Teju Nareddy <nareddyt@google.com>
Dor1s pushed a commit to google/oss-fuzz that referenced this issue Mar 9, 2020
[Example failure](https://oss-fuzz-build-logs.storage.googleapis.com/log-8eabbac0-bb8f-4f90-a840-f23efe427e0e.txt)

This only occurs on the fuzzers for some reason, not on Travis CI. Error is similar to bazelbuild/bazel#5640.

Change spawn strategy to `sandboxed` to work around this. Not sure why it was `local` to begin with (other than a slight performance improvement).

Tested locally to ensure this spawn strategy will work.

```
python infra/helper.py build_fuzzers --sanitizer address --engine libfuzzer --architecture x86_64 esp-v2
```

Signed-off-by: Teju Nareddy <nareddyt@google.com>
@philwo philwo added the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label Jun 15, 2020
@github-actions
Copy link

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 2.5 years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

@github-actions github-actions bot added the stale Issues or PRs that are stale (no activity for 30 days) label Mar 16, 2023
@github-actions
Copy link

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Mar 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Windows Windows-specific issues and feature requests P3 We're not considering working on this, but happy to review a PR. (No assignee) platform: windows stale Issues or PRs that are stale (no activity for 30 days) team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website type: bug
Projects
None yet
Development

No branches or pull requests

9 participants