This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug sanitizer/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test
- From: "vries at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 12 Feb 2016 16:07:35 +0000
- Subject: [Bug sanitizer/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test
- Auto-submitted: auto-generated
- References: <bug-68580-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580
--- Comment #8 from vries at gcc dot gnu.org ---
I managed to trigger the test returning 0 from the command line, by running it
in parallel:
...
$ ( export LD_LIBRARY_PATH=$(pwd -P)/install/lib64; for cnt in $(seq 1 400); do
(./a.out ; echo $? ) > log.$cnt 2>&1 & done )
$ egrep '^0$' log.* | wc -l
54
...
I can't be sure if that is the reason that the test is failing (by returning 0)
during running the testsuite, but it's certainly possible (I'm running it with
-j12).
So, I suspect that the test fails because pthread_create fails with EAGAIN due
to insufficient resources:
...
int
main ()
{
pthread_t th;
barrier_init (&barrier, 2);
if (pthread_create (&th, NULL, tf, NULL))
return 0;
...
Indeed in the testcase we do not distinguish between:
- return 0, case pthread_create failed, and
- return 0 at end of main, -fsanitize=thread failed to catch the race
condition.
It would probably be good to print an error message when pthread_create fails,
such that when looking at the fail in the testlog, we can easily see that that
is the reason it failed, and not expect it to reproduce otherwise.