This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: what to do with flaky tests?
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>