Open olologin opened 2 years ago
Right, turns out it was covered by already existing test: https://github.com/llvm/llvm-project/blob/main/compiler-rt/test/msan/dtls_test.c
OS is debian buster, glibc is 2.28 Also tried on debian bullseye, same result.
root@b30e30645388:/build/build# clang-14 -fPIC -fsanitize=memory -fsanitize-memory-track-origins -fno-omit-frame-pointer -g dtls_test.c -o main
root@b30e30645388:/build/build# clang-14 -fPIC -fsanitize=memory -fsanitize-memory-track-origins -fno-omit-frame-pointer -g dtls_test.c -DBUILD_SO -o main-so.so -shared
root@b30e30645388:/build/build# ./main
==24099==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x4a50a1 in Thread1 /build/build/dtls_test.c:33:7
#1 0x7fc496fd2fa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486:8
#2 0x7fc496d574ce in __clone /build/glibc-vjB4T1/glibc-2.28/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Uninitialized value was created by a heap allocation
#0 0x4537e0 in __interceptor_malloc (/build/build/main+0x4537e0) (BuildId: c53a116747654387bfa98d19a266e2b2ba84a1a2)
#1 0x7fc4970088b7 in allocate_dtv_entry /build/glibc-vjB4T1/glibc-2.28/elf/../elf/dl-tls.c:582:19
#2 0x7fc4970088b7 in allocate_and_init /build/glibc-vjB4T1/glibc-2.28/elf/../elf/dl-tls.c:607:31
#3 0x7fc4970088b7 in tls_get_addr_tail /build/glibc-vjB4T1/glibc-2.28/elf/../elf/dl-tls.c:787:31
SUMMARY: MemorySanitizer: use-of-uninitialized-value /build/build/dtls_test.c:33:7 in Thread1
Exiting
root@b30e30645388:/build/build# ldd ./main
linux-vdso.so.1 (0x00007ffec9d19000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f41f9e10000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f41f9e06000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f41f9c83000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f41f9c7e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f41f9c64000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f41f9aa3000)
/lib64/ld-linux-x86-64.so.2 (0x00007f41f9e3c000)
I think none of those dependencies in lld output have to be instrumented, right?
FWIW I recently found that DTLS support in sanitizers is broken: https://bugs.chromium.org/p/chromium/issues/detail?id=1275223#c15
Hi guys, MSAN is reporting false-positive with latest build of clang-14 (and with clang-12). Is it because some interceptor implementation is missing? Unfortunately I cannot simplify sources to reproduce it right now, but I think it might be some obvious problem. I also tested it in valgrind but everything is fine with this code. If it is not enough data for report - you can close this issue, I will reopen it as soon as obtain small reproducible source, maybe I will also be able to help with fix for this (if needed). Of course libc++ is instrumented on my side.