Re: what to do with flaky tests?

[Florian Weimer <fweimer at redhat dot com>]

* Szabolcs Nagy:

> On 07/05/2019 16:27, Florian Weimer wrote:
>> * Szabolcs Nagy:
>> 
>>>> The patch below uses process-shared barriers for synchronization.  I see
>>>> numbers like these when running it:
>>>>
>>>> $ time malloc/tst-mallocfork2 
>>>> info: signals received during fork: 833
>>>> info: signals received during free: 924
>>>> info: signals received during malloc: 3625
>>>>
>>>> real    0m5.996s
>>>> user    0m2.715s
>>>> sys     0m2.883s
>>>>
>>>> Due to code churn, it's not easy to verify if the changes interfere with
>>>> the original test objective.  However, I temporarily added this at the
>>>> beginning of the test:
>>>>
>>>>   {
>>>>     auto void *cb(void *closure) { pause (); return NULL; }
>>>>     xpthread_create (NULL, cb, NULL);
>>>>   }
>>>>
>>>> This puts the process into multi-threaded mode, and this still results
>>>> in a deadlock because none of the single-thread code paths are taken
>>>> anymore.  So I think the test still works as intended.
>>>>
>>>> Does this patch make the test pass for you?
>>>
>>> yes, the test now seems to pass reliably.
>>> on the problematic machine i see
>>>
>>> $ time ./testrun.sh malloc/tst-mallocfork2
>>> info: signals received during fork: 103
>>> info: signals received during free: 482
>>> info: signals received during malloc: 75
>>>
>>> real	0m22.477s
>>> user	0m10.366s
>>> sys	0m12.284s
>>>
>>> (the time does not vary much so the 100s
>>> timeout setting works now)
>> 
>> Do you think this is okay to push?  May I consider this as a patch
>> review?
>
> yes, sorry
>
> Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>

Thanks for the review.  Now pushed.

Florian