Re: what to do with flaky tests?

[Florian Weimer <fweimer at redhat dot com>]

* 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?

Thanks,
Florian