libsanitizer merge from upstream r196090

Konstantin Serebryany
Tue Jan 14 09:43:00 GMT 2014

I've started a separate topic about flaky tsan tests here:!topic/thread-sanitizer/KIok3F_b1oI


On Fri, Jan 10, 2014 at 7:20 PM, Jakub Jelinek <> wrote:
> On Fri, Jan 10, 2014 at 03:50:33PM +0400, Maxim Ostapenko wrote:
>> On Fri, Jan 10, 2014 at 10:39 AM, Jakub Jelinek<> wrote:
>> > Some of the tsan tests seems to FAIL randomly for quite a while
>> > (since they  were added), didn't have time to look if it is just
>> bugs in the test or
>> > some compiler issue or library issue.
>> When I've commited these tsan tests, all of them were passed on my
>> x86_64-unknown-linux-gnu 64bit system.
>> Should I review them more carefully?
> That would be nice.  The FAILs I'm seeing include e.g.
> FAIL: c-c++-common/tsan/simple_race.c  -O2  execution test
> FAIL: c-c++-common/tsan/simple_race.c  -O0  execution test
> FAIL: g++.dg/tsan/default_options.C  -O2  execution test
> (and various others in the past, though not sure if any of the
> pattern related failures could have something with libbacktrace
> symbolization not being there yet (note, I do not have
> /usr/bin/llvm-symbolizer installed on the testing box)).
> Both these tests don't report anything (well, default_options.C prints DONE),
> simply succeed (with dg-shouldfail that is a failure).
> I don't see anything wrong in the compiler output, the Thread?
> routines just call __tsan_func_entry, then __tsan_write4 (&Global);
> then __tsan_func_exit, so I don't see how it could be related to anything
> but the library.  Note the box is sometimes quite loaded (two make -j48
> regtests going on at the same time), but there is enough memory.
> Is the library perhaps timing sensitive, e.g. that it would track
> issues only if the two threads are actually concurrent rather than could be
> concurrent?  Say if the first pthread_create creates thread immediately,
> second pthread_create returns but the clone started thread isn't up yet,
> then pthread_join on the first thread finishes and the first thread is
> destroyed, then the second thread actually starts?
>         Jakub

More information about the Gcc-patches mailing list