libsanitizer merge from upstream r196090
Tue Jan 14 09:43:00 GMT 2014
I've started a separate topic about flaky tsan tests here:
On Fri, Jan 10, 2014 at 7:20 PM, Jakub Jelinek <firstname.lastname@example.org> 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<email@example.com> 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?
More information about the Gcc-patches