[TSAN] Fatal "unsupported VMA range" when running aarch64 binaries via qemu

[moha-gh]

Summary

We are trying to execute binaries compiled with TSAN for aarch64 on an x86_64 host via qemu-aarch64 and encounter

FATAL: ThreadSanitizer: unsupported VMA range
FATAL: Found 47 - Supported 39, 42 and 48

errors.

Environment is an Alpine Linux based (privileged) Docker container running on a Manjaro Linux host (but we've seen this issue on other systems as well).

$ uname -a
Linux ws 6.12.39-1-MANJARO #1 SMP PREEMPT_DYNAMIC Thu, 17 Jul 2025 20:46:35 +0000 x86_64 GNU/Linux

Details

I compiled the tiny_race example code from the TSAN documentation with both Clang 20 (20.1.8) and 19 (19.1.4).

$ cat /etc/os-release
NAME="Alpine Linux"
[...]
VERSION_ID=3.21.4
$ clang --version
Alpine clang version 20.1.8
Target: aarch64-poky-linux
[...]
$ clang -fsanitize=thread -g -O1 [...] -o race-c tiny_race.c

Then I tried to run it using qemu 8.2.7, 9.1.2 and 10.0.0. In all cases, TSAN errors out immediately with the error message given above.

My understanding of the VMA issue is limited, but it seems to be related to the -R size (QEMU_RESERVED_VA) option for qemu, so I played around with that. When setting it to a value that matches 39 or 42 bits, TSAN does indeed initalize, but still fails:

$ TSAN_OPTIONS=verbosity=2 /usr/bin/$QEMU -R 1024G ./race-c
==274347==Installed the sigaction for signal 11
==274347==Installed the sigaction for signal 7
==274347==Installed the sigaction for signal 8
==274347==Using llvm-symbolizer found at: /usr/bin/llvm-symbolizer
***** Running under ThreadSanitizer v3 (pid 274347) *****
==274347==__tls_get_addr: DTLS_Find 0x005555d5c180 1
==274347==__tls_get_addr: DTLS_NextBlock 0x005555d5c180 0
==274347==__tls_get_addr: 0x005555d54850 {0x1,0x0} => 0x005555d5c180; tls_beg: 0x005555d5c180; sp: 0x005555d547c8 num_live_dtls 1
==274347==__tls_get_addr: Can't guess glibc version
==274347==__tls_get_addr: DTLS_Find 0x005555d5c180 2
==274347==__tls_get_addr: 0x005555d54850 {0x2,0x0} => 0x005555d5c150; tls_beg: 0x005555d5c150; sp: 0x005555d547c8 num_live_dtls 1
==274347==__tls_get_addr: Can't guess glibc version
==274347==__tls_get_addr: DTLS_Find 0x005555d5c180 3
==274347==__tls_get_addr: 0x005555d54850 {0x3,0x0} => 0x005555d5c900; tls_beg: 0x005555d5c900; sp: 0x005555d547c8 num_live_dtls 1
==274347==__tls_get_addr: Can't guess glibc version
ThreadSanitizer: growing sync allocator: 0 out of 1048576*1024
ThreadSanitizer: growing heap block allocator: 0 out of 262144*4096
==274347==__tls_get_addr: DTLS_Find 0x005555d5c180 1
==274347==__tls_get_addr: DTLS_Find 0x005555d5c180 2
==274347==__tls_get_addr: DTLS_Find 0x005555d5c180 3
==274347==__tls_get_addr: DTLS_Find 0x005559f0f140 1
==274347==__tls_get_addr: DTLS_NextBlock 0x005559f0f140 1
==274347==__tls_get_addr: 0x005559f0de20 {0x1,0x0} => 0x005559f0f140; tls_beg: 0x005559f0f140; sp: 0x005559f0dd98 num_live_dtls 2
==274347==__tls_get_addr: Can't guess glibc version
==274347==__tls_get_addr: DTLS_Find 0x005559f0f140 2
==274347==__tls_get_addr: 0x005559f0de20 {0x2,0x0} => 0x005559f0f110; tls_beg: 0x005559f0f110; sp: 0x005559f0dd98 num_live_dtls 2
==274347==__tls_get_addr: Can't guess glibc version
==274347==__tls_get_addr: DTLS_Find 0x005559f0f140 3
==274347==__tls_get_addr: 0x005559f0de20 {0x3,0x0} => 0x005559f0f8c0; tls_beg: 0x005559f0f8c0; sp: 0x005559f0dd98 num_live_dtls 2
==274347==__tls_get_addr: Can't guess glibc version
ThreadSanitizer:DEADLYSIGNAL
ThreadSanitizer:DEADLYSIGNAL
==274347==ERROR: ThreadSanitizer: SEGV on unknown address 0x013558139dd0 (pc 0x00aaaabaeaec bp 0x005555d54a40 sp 0x005555d54a20 T274347)
==274347==The signal is caused by a UNKNOWN memory access.
ThreadSanitizer:DEADLYSIGNAL
ThreadSanitizer: nested bug in the same thread, aborting.

Values higher than 46 bits result in:

qemu-aarch64: /src/tsan/race-c: Unable to find a guest_base to satisfy all guest address mapping requirements
  0000000000000000-00007fffffffffff

Anything else we can try? Pointers would be highly appreciated, thanks!