I've started a separate topic about flaky tsan tests here: https://groups.google.com/forum/#!topic/thread-sanitizer/KIok3F_b1oI
--kcc On Fri, Jan 10, 2014 at 7:20 PM, Jakub Jelinek <ja...@redhat.com> 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<ja...@redhat.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? > > Jakub
