build: propagate ASAN/TSAN flags down to cmake_external deps.#6061
build: propagate ASAN/TSAN flags down to cmake_external deps.#6061htuch wants to merge 10 commits intoenvoyproxy:masterfrom
Conversation
While we await a solution for bazel-contrib/rules_foreign_cc#154 (comment), this PR provides a temporary workaround to get full ASAN/TSAN propagation as needed. Risk level: Low Testing: --config=clang-{tsan,asan}. This was broken strangely this morning on my distribution, after some clang-7 package upgrade this morning, due to the mismatched linker/compiler flags we previously had been sending to cmake_external builds. Signed-off-by: Harvey Tuch <htuch@google.com>
|
@htuch seems CI is failing, maybe you need newer image? |
|
@lizan seems some mystery compile error in |
|
Hmm, |
You might need to update autoconf: |
|
@PiotrSikora thanks for that pointer, I think we have the same issue. From config.log: .. and we seem to have an autoconf version prior to the bug fix ... Will look into updating the base image. |
Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
| ctxt.symlink(Label("//ci/prebuilt:BUILD"), "BUILD") | ||
|
|
||
| # Data files for build recipes | ||
| for f in ["gperftools.patch.gz"]: |
There was a problem hiding this comment.
Wouldn't it be easier to update autoconf, or simply hardcode -DHAVE_MMAP to ignore the breaking test?
There was a problem hiding this comment.
@lizan expressed a preference for this approach; for release versions we have fixed autoconf outputs, we will revert back to this when we next move to a release version.
|
Looks like a legit TSAN failure, libevent does some technically unsafe things by writing to a shared boolean across threads ( |
Signed-off-by: Harvey Tuch <htuch@google.com>
|
I have a workaround for the libevent TSAN issues, next up is the ASAN issue in LuaJIT at https://circleci.com/gh/envoyproxy/envoy/172877?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link. |
|
More TSAN errors, this time in dispatcher posting, will dig further tomorrow. |
| build:asan --copt -fsanitize=address,undefined | ||
| build:asan --linkopt -fsanitize=address,undefined | ||
| build:asan --copt -fno-sanitize=vptr | ||
| # TODO(htuch): these are temporary workarounds, remove when |
There was a problem hiding this comment.
nit: It's not clear which are "these", put them in the bottom?
While we await a solution for bazel-contrib/rules_foreign_cc#154 (comment), this PR provides a temporary workaround to get full ASAN/TSAN propagation as needed. This continues envoyproxy#6061, which had accumulated too much complicated merge history to work with after the recent gperftools/LuaJIT migration to rules_foreign_cc. Risk level: Low Testing: --config=clang-{tsan,asan}. This is broken in the latest CI images due to the mismatched linker/compiler flags we previously had been sending to cmake_external builds. Signed-off-by: Harvey Tuch <htuch@google.com>
|
Closing out in favor of cleaned up #6196. |
While we await a solution for
bazel-contrib/rules_foreign_cc#154 (comment), this PR provides a
temporary workaround to get full ASAN/TSAN propagation as needed.
Risk level: Low
Testing: --config=clang-{tsan,asan}. This was broken strangely this morning on my distribution,
after some clang-7 package upgrade this morning, due to the mismatched linker/compiler flags we
previously had been sending to cmake_external builds.
Signed-off-by: Harvey Tuch htuch@google.com