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
