This test case fails on powerpc64 BE. It used to also fail on LE but that was fixed recently (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79455) The failure for BE is a little different than for LE. The output of them is very similar except for function #1 in the traceback in the second section which is #1 pthread_mutex_init <null> (libpthread.so.0+0x00000000b61c) on powerpc64le and is #1 <null> <null> (libpthread.so.0+0x00000000e93c) on powerpc64 (BE). The function name is missing which looks like a problem. Full output on BE: WARNING: ThreadSanitizer: data race (pid=16676) Atomic read of size 1 at 0x000010020408 by thread T2: #0 pthread_mutex_lock gcc-trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:3608 (libtsan.so.0+0x00000006094c) #1 Thread2 c-c++-common/tsan/race_on_mutex.c:22 (race_on_mutex.exe+0x000010000fd4) Previous write of size 8 at 0x000010020408 by thread T1: #0 memset gcc-trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:558 (libtsan.so.0+0x0000000522dc) #1 <null> <null> (libpthread.so.0+0x00000000e93c) #2 Thread1 c-c++-common/tsan/race_on_mutex.c:12 (race_on_mutex.exe+0x000010000e9c) Location is global 'Mtx' of size 40 at 0x000010020408 (race_on_mutex.exe+0x000010020408) Thread T2 (tid=16848, running) created by main thread at: #0 pthread_create gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:900 (libtsan.so.0+0x0000000485c4) #1 main c-c++-common/tsan/race_on_mutex.c:32 (race_on_mutex.exe+0x0000100010b8) Thread T1 (tid=16836, finished) created by main thread at: #0 pthread_create gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:900 (libtsan.so.0+0x0000000485c4) #1 main c-c++-common/tsan/race_on_mutex.c:31 (race_on_mutex.exe+0x000010001098) SUMMARY: ThreadSanitizer: data race c-c++-common/tsan/race_on_mutex.c:22 in Thread2
Good, I can help you with that. Can you please investigate why unwinding fails to identify function name? I guess softening the pattern scan can lead to catch basically every function :/
Segher any investigation about this?
It apparently started failing last week of January 2017. Only 64-bit fails, -m32 is fine. I don't know where that missing function name is coming from.
(In reply to Segher Boessenkool from comment #3) > It apparently started failing last week of January 2017. Only 64-bit > fails, -m32 is fine. > > I don't know where that missing function name is coming from. Yep, it must start in r244854 where we enable TSAN on power. So we don't have much detailed information should I disable it for power?
Why disable it? Can the feature not work, can the test not work? Disabling the test is papering over the problem as far as I see.
(In reply to Segher Boessenkool from comment #5) > Why disable it? Can the feature not work, can the test not work? > > Disabling the test is papering over the problem as far as I see. The test does not work :) So should we generalize more the scanned back-trace in order to survive '#1 <null> <null>' ?
Why can't the unwinder find the function name here?
I've just used gcc110 and gcc112 machine (ppc64 and ppc64le) and both print following stack-trace in the tsan error: #0 memset ../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:709 (libtsan.so.0+0x55abc) #1 __GI___pthread_mutex_init <null> (libpthread.so.0+0xf2ac) #2 Thread1 c-c++-common/tsan/race_on_mutex.c:12 (race_on_mutex.exe+0x10000f00) I also verified that non-sanitized version in gdb also has missing source file for the __GI___pthread_mutex_init function. Thus '<null>' is here proper value. Can you seurer test the problematic ppc64 machine where you see: #1 <null> <null> What do you see in gdb if you put a breakpoint to memset function? Thanks
Nothing, it never reaches memset before it exits.
(In reply to Segher Boessenkool from comment #9) > Nothing, it never reaches memset before it exits. Are you sure? I was able to place breakpoint on memset and ~14th iteration of the breakpoint was really mutex init function. Can you please double check it?
I rebuilt everything, and it still does not break at all.
It does break if I set the breakpoints before the shared libs have loaded. Thread 3 "a.out" hit Breakpoint 1, 0x00003fffb6e0c860 in .__memset_power7 () from /lib64/libc.so.6 #0 0x00003fffb6e0c860 in .__memset_power7 () from /lib64/libc.so.6 #1 0x00003fffb7055b10 in __interceptor_memset (dst=0x100201f0 <Mtx>, v=<optimized out>, size=40) at /home/segher/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:709 #2 0x00003fffb6f9f2b0 in .pthread_mutex_init () from /lib64/libpthread.so.0 #3 0x00003fffb704d58c in __interceptor_pthread_mutex_init ( m=0x100201f0 <Mtx>, a=0x0) at /home/segher/src/gcc/libsanitizer/tsan/tsan_interceptors.cc:1132 #4 0x0000000010000dc4 in .Thread1 () #5 0x00003fffb7049454 in __tsan_thread_start_func (arg=0x3fffffffeda0) at /home/segher/src/gcc/libsanitizer/tsan/tsan_interceptors.cc:905 #6 0x00003fffb6f9c95c in .start_thread () from /lib64/libpthread.so.0 #7 0x00003fffb6e83bbc in .__clone () from /lib64/libc.so.6
It is trying to match #[01] (__)?pthread_mutex_init but instead it gets #1 __GI___pthread_mutex_init
Changing that (__)? to ((__GI_)?__)? is preapproved if it works. Those are just glibc internal aliases which are in the symbol table too though, so if you have full debug info for libpthread.so rather than just what .dynsym contains it is possible you get it instead.
Author: segher Date: Fri Feb 23 14:17:35 2018 New Revision: 257932 URL: https://gcc.gnu.org/viewcvs?rev=257932&root=gcc&view=rev Log: Fix tsan race_on_mutex.c testcase (PR80551) The testcase did not match the glibc internal names while it should. This fixes it. gcc/testsuite/ PR testsuite/80551 * c-c++-common/tsan/race_on_mutex.c: Change regexp to allow __GI___pthread_mutex_init as well. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/tsan/race_on_mutex.c
Fixed on trunk. Does this actually fail on GCC 7? The regexp there should work AFAICS.
Let's close it, if somebody sees problem on GCC 7, then we should reopen it.
It fails on 7 (and always has). The fix for PR79455 needs to be applied before this one can be.
.
Author: marxin Date: Tue Mar 6 20:07:49 2018 New Revision: 258300 URL: https://gcc.gnu.org/viewcvs?rev=258300&root=gcc&view=rev Log: Backport r257932 2018-03-06 Martin Liska <mliska@suse.cz> Backport from mainline 2018-02-23 Segher Boessenkool <segher@kernel.crashing.org> PR testsuite/80551 * c-c++-common/tsan/race_on_mutex.c: Change regexp to allow __GI___pthread_mutex_init as well. Modified: branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/c-c++-common/tsan/race_on_mutex.c
Should be fixed now.