| Issue |
83566
|
| Summary |
[Support] Bugprone usage of __has_feature(address_sanitizer) in Allocator
|
| Labels |
bug,
mlir:core,
llvm:support
|
| Assignees |
|
| Reporter |
Dinistro
|
tl;dr:
`llvm/Support/Allocator.h` transitively uses `__has_feature(address_sanitizer)` to decide if it uses `__msan_*` and `__asan_*` markers and if it should allocate a red zone. This is very problematic when this header is pulled into an LLVM compilation unit but is also made available through some LLVM template to downstream users.
**Extended bug explanation**
We observed an ASAN crash in the following setup:
We build LLVM + MLIR without sanitizers enabled, but have a downstream project that is build with ASAN. Due to relying on MLIR's `StorageUniquer`, which is a templated implementation in a header, we pull in a copy of `BumpPtrAllocatorImpl::Allocate`. This function changes behavior, depending on ASAN being enabled or not:
https://github.com/llvm/llvm-project/blob/0e9a102129c07d31dccec06cb45f6e2a74c6e590/llvm/include/llvm/Support/Allocator.h#L156-L159
Additionally, this code contains multiple `__msan_*` and `__asan_*` usages.
Unfortunately, other parts of MLIR's `StorageUniquer` are implemented in a `.cpp` file, which result in it being compiled without ASAN. This is problematic, due the a non-ASAN build replacing all `__msan_*` and `__asan_*` function with empty macros.
https://github.com/llvm/llvm-project/blob/2d98d763a8e627b2d1a18a9cdd1c62a4b58be3aa/llvm/include/llvm/Support/Compiler.h#L441-L461
Therefore, some of the poison marking is compiled in, while unpoison markings are omitted. This can therefore lead to ASAN violations that very tricky to hunt down.
CC @ibookstein
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
