Open real-or-random opened 1 year ago
Seems I'm encountering the same issue on rockchip RK3588. The clang+llvm is obtained via latest github release.
firefly@firefly ~> clang -fsanitize=memory ./hello.c -o hello
firefly@firefly ~> ./hello
MemorySanitizer: CHECK failed: sanitizer_allocator_primary64.h:133 "((kSpaceBeg)) == ((address_range.Init(TotalSpaceSize, PrimaryAllocatorName, kSpaceBeg)))" (0xe00000000000, 0xfffffffffffffff4) (tid=51745)
<empty stack>
firefly@firefly ~ [1]> clang --version
clang version 17.0.1 (http://git.linaro.org/toolchain/jenkins-scripts.git 09f505cadfbe9987730e641398ab9a2ca0cdb67f)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/firefly/clang+llvm-17.0.1-aarch64-linux-gnu/bin
firefly@firefly ~> uname -a
Linux firefly 5.10.160 #111 SMP Tue Jul 4 11:41:59 CST 2023 aarch64 GNU/Linux
firefly@firefly ~> lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye
Same problem here with clang 19.1.1, ARM64, where VA size is 48bits crashing before program even starts.
AddressSanitizer: CHECK failed: sanitizer_allocator_primary64.h:133 "((kSpaceBeg)) == ((address_range.Init(TotalSpaceSize, PrimaryAllocatorName, kSpaceBeg)))" (0x500000000000, 0xfffffffffffffff4) (tid=1060037)
Same problem with my g++ 13.2.0 AddressSanitizer: CHECK failed: sanitizer_allocator_primary64.h:131 "((kSpaceBeg)) == ((address_range.Init(TotalSpaceSize, PrimaryAllocatorName, kSpaceBeg)))" (0x500000000000, 0xfffffffffffffff4) (tid=11456)
Symptoms
MSan fails to init with
Environment
This is when running an MSan-instrumented aarch64 binary via
qemu-aarch64
. I'm using a clang snapshot:People report similar issues on Raspberry Pi 4, with ASan, and with Clang 16 and Clang 17, while Clang 15 works:
So this seems to be a regression between 15 and 16.
Possible causes and fix
I have a strong suspicion that the reason for this is the commit https://github.com/llvm/llvm-project/commit/a588cfe37ea36ec4fae35a233a13d3557fba86e9, but I haven't tested recompiling with
-DSANITIZER_CAN_USE_ALLOCATOR64=0
.When I use qemu's strace functionality, I get this just before the crash:
And note that the value
0xfffffffffffffff4
from the assertion is equal to-12
. Here,0x0000e00000000000
is a 48-bit address, but perhaps QEMU's emulation supports only smaller (39 bits)? [1] I suspect that the Raspberry Pi 4 also has a virtual address space smaller than 48 bits. When I try this with Clang 14, I see only mmap calls up to address0x0000006000000000
(which is a 39-bit address).The AArch64 memory layout on Linux can vary a lot (https://www.kernel.org/doc/html/v5.8/arm64/memory.html). Possible virtual address sizes are 39 bits, 42 bits, 48 bits, and 52 bits. Perhaps it's a good idea to detect this at runtime in the 64-bit allocator?
(note: Not sure if this is the right place to report. It seems to me that this is a compiler-rt issue, which seems to be tracked here? But please close if the existing https://github.com/google/sanitizers/issues/1674 is a better place to track this.)
edit: [1] After some more experimentation, I am not convinced that's true. I see QEMU placing the code 47-bit addresses. So I don't know why it doesn't like
0x0000e00000000000
. Its emulation of the Linux memory layout may not be perfect. I might reach out to them. But this does not change much about the validity of this bug, which still seems to occur on Raspberry Pi (without any emulation layer).