-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Get the ASAN toolchain working again #7604
Conversation
Various fixes to enable ASAN to finally work (linux x64 only). Note that this found several ASAN failures in the Anderson2021 autoscheduler tests, which are *not* fixed yet; I'll fix thus in a subsequent PR.
(Note that I'm pushing some temporary debugging code here to try to catch a failure that so far only repros on the buildbots, but not locally -- please ignore when reviewing, for now at least) |
(Harvested from #7604 to land separately)
I'm going to try this locally before doing a full review. There are a few things here that are raising alarm bells for certain toolchain configurations. |
Thanks. Everything about ASAN (or really, any of the sanitizers) is pretty ticklish, due to the combination of our unorthodox build setup (eg building to bitcode) and CMake being CMake. |
* Fix PCH build failures (Harvested from #7604 to land separately) * Update CMakeLists.txt
When building with clang 16, I get the following error:
Things I did that allowed the build to finish:
I don't recommend (1)... The default is I'm partial to a mix of 2 and 3. |
I thought that we had to explicitly link to FWIW, I didn't even test with LLVM16 -- my assumption here is that we'll only do ASAN builds with top-of-tree, so as long as it works with LLVM/Clang17+, we're fine. |
Okay, if Clang 17 doesn't need any of this, then I'm cool with the change. Well, almost -- there's more in here than just the toolchain changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm proposing a less ad-hoc extension point that feels better to send downstream. I can open a PR-to-PR if you agree with the change, but would prefer not to do this work.
cmake/HalideGeneratorHelpers.cmake
Outdated
if (Halide_SHARED_ASAN_RUNTIME_LIBRARY) | ||
# ASAN's Leak detector will report that we leaked all the PyBind11 | ||
# Module-support code, so disable it here. | ||
set(EXTRA_ENV_VARS ASAN_OPTIONS=detect_leaks=0 ${Halide_SANITIZER_ENV_VARS}) | ||
endif () | ||
set(GENERATOR_CMD ${CMAKE_COMMAND} -E env PYTHONPATH=${PYTHONPATH} ${EXTRA_ENV_VARS} ${Python3_EXECUTABLE} $<SHELL_PATH:${py_src}>) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As this is code is part of our downstream package interface, the Halide_SHARED_ASAN_RUNTIME_LIBRARY
variable would need to be documented. I think a more flexible design would be to add a Halide_PYTHON_LAUNCHER
variable that works like the familiar CMAKE_CXX_COMPILER_LAUNCHER
variable.
To implement that, this code would be:
if (Halide_SHARED_ASAN_RUNTIME_LIBRARY) | |
# ASAN's Leak detector will report that we leaked all the PyBind11 | |
# Module-support code, so disable it here. | |
set(EXTRA_ENV_VARS ASAN_OPTIONS=detect_leaks=0 ${Halide_SANITIZER_ENV_VARS}) | |
endif () | |
set(GENERATOR_CMD ${CMAKE_COMMAND} -E env PYTHONPATH=${PYTHONPATH} ${EXTRA_ENV_VARS} ${Python3_EXECUTABLE} $<SHELL_PATH:${py_src}>) | |
# TODO: when upgrading to CMake 3.24+ add `--` before `${Halide_PYTHON_LAUNCHER}` | |
set(GENERATOR_CMD ${CMAKE_COMMAND} -E env PYTHONPATH=${PYTHONPATH} ${Halide_PYTHON_LAUNCHER} ${Python3_EXECUTABLE} $<SHELL_PATH:${py_src}>) |
Then, in our toolchain file, we could set:
set(
Halide_PYTHON_LAUNCHER
${CMAKE_COMMAND} -E env ASAN_OPTIONS=detect_leaks=0 LD_PRELOAD=${Halide_SHARED_ASAN_RUNTIME_LIBRARY}
)
cmake/toolchain.linux-x64-asan.cmake
Outdated
set(Halide_SHARED_ASAN_RUNTIME_LIBRARY "${Halide_SHARED_ASAN_RUNTIME_LIBRARY}" | ||
CACHE FILEPATH "Library to preload when running Python tests.") | ||
|
||
set(Halide_SANITIZER_ENV_VARS "LD_PRELOAD=${Halide_SHARED_ASAN_RUNTIME_LIBRARY}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
set(Halide_SANITIZER_ENV_VARS "LD_PRELOAD=${Halide_SHARED_ASAN_RUNTIME_LIBRARY}") | |
set( | |
Halide_PYTHON_LAUNCHER | |
${CMAKE_COMMAND} -E env ASAN_OPTIONS=detect_leaks=0 LD_PRELOAD=${Halide_SHARED_ASAN_RUNTIME_LIBRARY} | |
) |
As described above.
python_bindings/CMakeLists.txt
Outdated
if (Halide_SANITIZER_ENV_VARS) | ||
list(PREPEND ARG_ENVIRONMENT ${Halide_SANITIZER_ENV_VARS}) | ||
endif () |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if (Halide_SANITIZER_ENV_VARS) | |
list(PREPEND ARG_ENVIRONMENT ${Halide_SANITIZER_ENV_VARS}) | |
endif () |
Then, below (GitHib won't let me comment there 😠), in the call to add_test
replace
COMMAND Python3::Interpreter
with
COMMAND ${Halide_PYTHON_LAUNCHER} "${Python3_EXECUTABLE}"
@@ -42,6 +42,7 @@ if (WITH_PYTHON_BINDINGS) | |||
set_tests_properties(li2018_gradient_autoscheduler_test_py PROPERTIES | |||
DEPENDS li2018_test | |||
LABELS "li2018;autoschedulers;auto_schedule" | |||
ENVIRONMENT "${Halide_SANITIZER_ENV_VARS}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ENVIRONMENT "${Halide_SANITIZER_ENV_VARS}" |
Same deal with add_test(... COMMAND Python3::Interpreter ...)
above. Use the Halide_PYTHON_LAUNCHER
variable.
* Use new Halide_PYTHON_LAUNCHER to set env vars * Update CMake docs for Halide_SANITIZER_ENV_VARS --------- Co-authored-by: Alex Reinking <[email protected]>
With your changes merged, is this good to go now, or are more changes needed? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM now
* Fix PCH build failures (Harvested from halide#7604 to land separately) * Update CMakeLists.txt
* Get the ASAN toolchain working again Various fixes to enable ASAN to finally work (linux x64 only). Note that this found several ASAN failures in the Anderson2021 autoscheduler tests, which are *not* fixed yet; I'll fix thus in a subsequent PR. * Remove stuff that I didn't mean to check in * Configure cuda-specific tests properly too * trigger buildbots * Update CodeGen_LLVM.cpp * Update CodeGen_LLVM.cpp * Fix sloppiness? * Update CMakeLists.txt * trigger buildbots * Use Halide_PYTHON_LAUNCHER to implement ASAN toolchain fixes (halide#7657) * Use new Halide_PYTHON_LAUNCHER to set env vars * Update CMake docs for Halide_SANITIZER_ENV_VARS --------- Co-authored-by: Alex Reinking <[email protected]> --------- Co-authored-by: Alex Reinking <[email protected]> Co-authored-by: Alex Reinking <[email protected]>
Various fixes to enable ASAN to finally work (linux x64 only).
Note that this found
severalone real ASAN failure in the Anderson2021 autoscheduler tests, which is not fixed yet; I'll fix thus in a subsequent PR.