Re: [RFC, PR68580] Handle pthread_create error in tsan testsuite

[Dmitry Vyukov <dvyukov at google dot com>]

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 <dvyukov@google.com> wrote:
> On Mon, Feb 15, 2016 at 7:00 AM, Tom de Vries <Tom_deVries@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