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

Alexey Samsonov via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 29 11:08:04 PST 2016


Sure. In this case, IMO it makes more sense to relax the expected output
rather than XFAIL the test.

On Mon, Feb 29, 2016 at 11:03 AM, Dmitry Vyukov <dvyukov at google.com> wrote:

> 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.
>



-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160229/fe81db9f/attachment-0001.html>


More information about the llvm-commits mailing list