Bug ID: 36326
           Summary: Sanitizers fail to get dynamic TLS sizes properly
                    starting with glibc 2.25
           Product: new-bugs
           Version: trunk
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs

Briefly:  There is a change in glibc 2.25 where memalign is no longer used for
tls allocations which breaks the sanitizers.  I see this on powerpc64 systems
but it will probably affect everyone.


Background details:
I updated a powerpc64 be system from fedora 25 (glibc 2.24) to fedora 26 (glibc
2.25) and several test cases started failing that deal with dynamic thread
local storage.

Failing Tests (3):
    LeakSanitizer-AddressSanitizer-powerpc64 ::
    LeakSanitizer-Standalone-powerpc64 :: TestCases/Linux/
    MemorySanitizer-POWERPC64 :: dtls_test.c

I looked at dtls_test.c in detail

******************** TEST 'MemorySanitizer-POWERPC64 :: dtls_test.c' FAILED
/home/seurer/llvm/build/llvm-test/./bin/clang  -fsanitize=memory
-mno-omit-leaf-frame-pointer -fno-omit-frame-pointer
-fno-optimize-sibling-calls  -m64  -gline-tables-only -g
/home/seurer/llvm/llvm-test/projects/compiler-rt/test/msan/dtls_test.c -o
/home/seurer/llvm/build/llvm-test/./bin/clang  -fsanitize=memory
-mno-omit-leaf-frame-pointer -fno-omit-frame-pointer
-fno-optimize-sibling-calls  -m64  -gline-tables-only -g
Exit Code: 77

Command Output (stdout):
==12029==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x10d636528 in Thread1
    #1 0x10d635630 in __msan::MsanThread::ThreadStart()
    #2 0x10d5c07c0 in MsanThreadStartFunc(void*)
    #3 0x7fff819dbf54 in start_thread (/lib64/power7/
    #4 0x7fff8172657c in __GI___clone (/lib64/power7/

SUMMARY: MemorySanitizer: use-of-uninitialized-value
/home/seurer/llvm/llvm-test/projects/compiler-rt/test/msan/dtls_test.c:22:7 in

If I run the test with sanitizer verbosity set to 2 on a system with glibc 2.24
I see this:

==39955==__tls_get_addr: DTLS_Resize 0x7fffaa73ebe0 0
==39955==__tls_get_addr: 0x7fffaaa6ff30 {0x000000000003,0xffffffffffff8000} =>
0x7fffa9e40000; tls_beg: 0x7fffa9e40000; sp: 0x7fffaa73d6f0 num_live_dtls 1
==39955==__tls_get_addr: glibc <=2.18 suspected;

Huh, the debug output is wrong about the glibc version but it does work.  the
"tls=" line shows it got an appropriate looking size.

Now if I run it on the system that got updated to fedora 26 which has glibc
2.25 or I build my own glibc 2.25 on the system were it previously worked:

==87783==__tls_get_addr: DTLS_Resize 0x7fff810febe0 0
==87783==__tls_get_addr: 0x7fff8142ff30 {0x000000000003,0xffffffffffff8000} =>
0x7fff807f0000; tls_beg: 0x7fff807f0000; sp: 0x7fff810fd6d0 num_live_dtls 1
==87783==__tls_get_addr: Can't guess glibc version

When the code in can't "guess the glibc version" it
uses 0 for the tls size which is probably what causes all the failures.

You are receiving this mail because:
You are on the CC list for the bug.
llvm-bugs mailing list

Reply via email to