This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]