If we are talking about pr 68580, then I would try: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580#c2 first.
On Mon, Feb 15, 2016 at 8:18 AM, Dmitry Vyukov <dvyu...@google.com> wrote: > 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
