On Mon, Feb 15, 2016 at 7:00 AM, Tom de Vries <tom_devr...@mentor.com> wrote: > Hi, > > Occasionally, I've been running into this failure while running the tsan > testsuite: > ... > FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test > ... > > I've also observed a potential similar occurrence here ( > https://gcc.gnu.org/ml/gcc-regression/2015-08/msg00147.html ). > > Initially, I couldn't reproduce it on the command line. > > Then I tried mimicking heavy load situations that might arise while running > the testsuite (I test with -j12 on a server), by running the test in > parallel, and found that in that case pthread_create fails, and the test > returns 0, which combined with the dg-shouldfail, makes the execution test > fail. > > So I suspect the failure I see while running the testsuite is the result of > pthread_create failure. > > The problem is that I can't be sure, given that in the testcase we do not > distinguish between: > - return 0, case pthread_create failed, and > - return 0 at end of main, case -fsanitize=thread failed to catch the > race condition. > > Note also that it's possible that many other tsan tests are failing in > pthread_create, but that this goes unnoticed because we don't test for the > result of pthread_create in most tests. > > This untested patch is an attempt at structurally testing and handling the > result of pthread_create in the tsan testsuite, using this macro: > ... > #define PTHREAD_CREATE(thread, attr, start_routine, arg) \ > { \ > int res = pthread_create (thread, attr, start_routine, arg);\ > if (res) \ > { \ > error (0, res, "pthread_create failed with"); \ > exit (0); \ > } \ > } > ... > > If this patch is committed, I should at least be able to find out if indeed > the failure I observe is related to resource exhaustion. > > Good idea? Any other comments?
Hi Tom, Yes, I guess we need to check return values. I am not sure how we can handle ENOMEMs in tests, but at least knowing the failure reason is valuable. We also suspect failing mmap's in some tests on some test bots. But changes to tsan runtime and tests should go into llvm repository first and then be integrated into gcc repository. If you never sent changes to llvm we can help. llvm tsan tests contain test.h file (probably what's called test_barrier.h in gcc), you can put the macro there. test.h should already be included into all tests. Thanks
