[compiler-rt] r261986 - [TSAN] XFAIL race_on_mutex.cc for MIPS

[Dmitry Vyukov via llvm-commits]

On Mon, Feb 29, 2016 at 8:00 PM, Alexey Samsonov <vonosmas at gmail.com> wrote:
> On Mon, Feb 29, 2016 at 5:09 AM, sagar <sagar.thakur at imgtec.com> wrote:
>>
>> Hi,
>>
>> The stack trace produced by TSan is:
>>
>>   Previous write of size 8 at 0x0120ed2930 by thread T1:
>>     #0 memset
>> /home/slt/LLVM/llvm/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:678
>> (race_on_mutex.c.tmp+0x0120071808)
>>     #1 __GI___pthread_mutex_init
>> /build/glibc-g99ldr/glibc-2.19/nptl/pthread_mutex_init.c:84
>> (libpthread.so.0+0x000000d634)
>>     #2 <null>
>> /home/slt/LLVM/llvm/projects/compiler-rt/test/tsan/race_on_mutex.c:11
>> (race_on_mutex.c.tmp+0x01200ea59c)
>>
>> The actual cause may be that the memset call at pthread_mutex_init.c:84 is
>> not in-lined for mips where as it is in-lined for x86 targets.
>> Should we adjust the expected output?
>
>
> So, do I understand correctly that on MIPS we do call pthread_mutex_init()
> interceptor, which then calls real pthread_mutext_init() from libpthread.so,
> which calls memset(), and TSan records this memset as "memory write",
> instead of explicit "MemoryWrite()" from MutexCreate()?
>
> If that's the case, then we can consider fixing the interceptor code
> instead. Generally, in sanitizers we annotate that a certain memory region
> will be
> accessed by the actual libc/libpthread function before we call this actual
> function. Maybe, we can follow the same approach here, and call
> MemoryWrite()
> on mutex from mutex-related interceptors before we're calling the "real"
> function. Dmitry, WDYT?

Tsan does not guarantee that the report will include the oldest/newest
memory access. It's more-or-less random.