test/ci: support for clang asan/tsan in build and travis.#904
test/ci: support for clang asan/tsan in build and travis.#904htuch merged 3 commits intoenvoyproxy:masterfrom
Conversation
bazel/README.md
Outdated
There was a problem hiding this comment.
Ah, thanks. I've been meaning to ask you why we didn't have ubsan.
ci/do_ci.sh
Outdated
There was a problem hiding this comment.
Should this be --config=clang-tsan ?
There was a problem hiding this comment.
Ah yeah, snafu. It does actually pass with clang-tsan, will update.
tools/bazel.rc
Outdated
There was a problem hiding this comment.
Any reason why we don't use -fsanitize=undefined here too?
There was a problem hiding this comment.
Too many unaligned pointer issues. We can fix these later if we care (certainly a performance advantage and more interesting as we consider running on more than just x86), I'll add a TODO.
There was a problem hiding this comment.
Out of curiosity where are the unaligned pointer issues?
mattklein123
left a comment
There was a problem hiding this comment.
LGTM. Needs master merge, also, might be worth it to just put bazel.debug target into this PR but up to you.
There was a problem hiding this comment.
nit: can you fix this to be dir_exists
|
I'm going to split out the code changes to deal with UBSAN from this PR and do a full rebase, there are now enough code changes that it makes sense to have them considered in distinct PRs. |
* Add --config={clang-asan,clang-tsan} configuration option to Bazel CLI for when building with
clang-5.0.
* Add clang-asan, which also checks some static initialization order stuff.
* Add ubsan to asan/clang-asan configs, the two play nicely together.
* Switch bazel.asan from gcc-4.9+asan to clang-5.0+clang-asan.
* Add bazel.tsan CI target, enabled in .travis.yml.
MSAN is not included due to the issue discussed at envoyproxy#443.
Automatic merge from submit-queue. [DO NOT MERGE] Auto PR to update dependencies of proxy This PR will be merged automatically once checks are successful. ```release-note none ```
This is what other mallocs do (glibc malloc and jemalloc). The idea is malloc is usually initialized very eary. So if we register atfork handler at that time, we're likely to be first. And that makes our atfork handler a bit safer, since there is much less chance of some other library installing their "take all locks" handler first and having fork take malloc lock before library's lock and deadlocking. This should address issue envoyproxy#904.
**Description** The build tags were present for all integration tests under ./tests directory such as e2e, crdcel, extproc, and controller testing where each of them is using the built artifact rather than the normal unit tests. --------- Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>
Add --config={clang-asan,clang-tsan} configuration option to Bazel CLI for when building with
clang-5.0.
Add clang-asan, which also checks some static initialization order stuff.
Add ubsan to asan/clang-asan configs, the two play nicely together.
Switch bazel.asan from gcc-4.9+asan to clang-5.0+clang-asan.
Add bazel.tsan CI target, enabled in .travis.yml.
Minor fixes to filesystem_impl_test and uuid_util_test that were necessary to make ASAN/UBSAN
combo on clang-5.0 work.
MSAN is not included due to the issue discussed at #443.