Bug 80551 - c-c++-common/tsan/race_on_mutex.c fails on powerpc
Summary: c-c++-common/tsan/race_on_mutex.c fails on powerpc
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: testsuite (show other bugs)
Version: 8.0
: P3 normal
Target Milestone: 8.0
Assignee: Martin Liška
URL:
Keywords:
Depends on: 79455
Blocks:
  Show dependency treegraph
 
Reported: 2017-04-27 18:42 UTC by seurer
Modified: 2018-03-06 20:08 UTC (History)
4 users (show)

See Also:
Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
Build: powerpc64-unknown-linux-gnu
Known to work: 8.0
Known to fail: 7.3.0
Last reconfirmed: 2017-04-28 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description seurer 2017-04-27 18:42:31 UTC
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
Comment 1 Martin Liška 2017-04-28 09:17:30 UTC
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 :/
Comment 2 Martin Liška 2017-08-02 09:01:21 UTC
Segher any investigation about this?
Comment 3 Segher Boessenkool 2017-08-02 13:06:32 UTC
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.
Comment 4 Martin Liška 2017-08-10 07:59:02 UTC
(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?
Comment 5 Segher Boessenkool 2017-08-10 11:47:29 UTC
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.
Comment 6 Martin Liška 2017-08-10 11:50:37 UTC
(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>' ?
Comment 7 Segher Boessenkool 2017-08-10 12:01:14 UTC
Why can't the unwinder find the function name here?
Comment 8 Martin Liška 2018-02-19 18:44:41 UTC
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
Comment 9 Segher Boessenkool 2018-02-19 20:10:32 UTC
Nothing, it never reaches memset before it exits.
Comment 10 Martin Liška 2018-02-20 08:22:46 UTC
(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?
Comment 11 Segher Boessenkool 2018-02-22 16:46:26 UTC
I rebuilt everything, and it still does not break at all.
Comment 12 Segher Boessenkool 2018-02-22 17:00:41 UTC
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
Comment 13 Segher Boessenkool 2018-02-23 13:54:42 UTC
It is trying to match

#[01] (__)?pthread_mutex_init

but instead it gets

#1 __GI___pthread_mutex_init
Comment 14 Jakub Jelinek 2018-02-23 13:58:02 UTC
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.
Comment 15 Segher Boessenkool 2018-02-23 14:18:06 UTC
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
Comment 16 Segher Boessenkool 2018-02-23 14:50:36 UTC
Fixed on trunk.  Does this actually fail on GCC 7?  The regexp there should
work AFAICS.
Comment 17 Martin Liška 2018-02-23 15:24:46 UTC
Let's close it, if somebody sees problem on GCC 7, then we should reopen it.
Comment 18 Segher Boessenkool 2018-02-23 15:33:29 UTC
It fails on 7 (and always has).  The fix for PR79455 needs to be applied before
this one can be.
Comment 19 Segher Boessenkool 2018-02-23 15:42:49 UTC
.
Comment 20 Martin Liška 2018-03-06 20:08:24 UTC
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
Comment 21 Martin Liška 2018-03-06 20:08:56 UTC
Should be fixed now.