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