[RFC, PR68580] Handle pthread_create error in tsan testsuite
Mon Feb 15 10:56:00 GMT 2016
On Mon, Feb 15, 2016 at 11:45 AM, Tom de Vries <Tom_deVries@mentor.com> wrote:
> On 15/02/16 10:07, Bernd Edlinger wrote:
>> On 15/02/16 09:07, Tom de Vries wrote:
>>>> >>On 15/02/16 08:24, Dmitry Vyukov wrote:
>>>> >> If we are talking about pr 68580, then I would try:
>>>> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580#c2
>>>> >> first.
>>> >As I tried to explain in the follow-up comment
>>> > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580#c3 ),
>>> >since unfortunately I have no reliable way of reproducing the failure,
>>> > there's no defined way to 'try' something.
>> But your proposed patch is also only guessing.
> I've tried to be as clear as possible in the RFC submission that I'm not
> certain about the cause of the failure, and that the patch is proposing a
> fix that would make that guessed failure cause explicit.
>> Sure pthread_create can fail, as malloc and mmap.
>> But if that is the reason for the failure it would happen
>> just randomly, everywhere.
>> Why do you think that only this test case shows the problem?
> As I explained in the RFC submission, my reasoning there was that the test
> is one of the very few test cases that tests the result of pthread_create
> and then returns 0, which causes the failure in combination with
> But thinking about it some more, even if pthread_create would fail, causing
> the testcase to fail in execution, allowing the execution test to pass due
> to dg-shouldfail, presumably the dg-output test would still fail in that
> case, so my reasoning was not sound.
> So I suppose you're right, indeed the pthread_create fail hypothesis is not
> the most logical one.
> Still, the patch is an improvement irrespective of the PR that inspired it,
> and perhaps a lot more library calls should be checked for errors that just
>> I think Dmitry's comment may be right on the point.
> If someone proposes that as a patch for the testcase, great. I'm more that
> willing to test that in my setup to be able to claim 'bootstrapped and
> reg-tested on x86_64' in the submission.
> I'm just trying to point out that I cannot 'try' out that patch and come
> back with the conformation that 'the patch fixes the failure', given the
> nature of the failure.
Yes, we can't directly test a fix. But s/int/long long/ is still the
right thing to do. We do it in other tests for similar reasons. We can
submit it and see if flakes remain or go away.
More information about the Gcc-patches