This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: what to do with flaky tests?
- From: Florian Weimer <fweimer at redhat dot com>
- To: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, nd <nd at arm dot com>
- Date: Fri, 03 May 2019 12:29:08 +0200
- Subject: Re: what to do with flaky tests?
- References: <2573599d-e2e0-118a-29c4-bede104930d9@arm.com>
* Szabolcs Nagy:
> currently these tests are flaky on the aarch64 buildbot:
>
> FAIL: malloc/tst-mallocfork2
> FAIL: nptl/tst-eintr1
>
> the first one is a timeout: the test can take unbounded time
> since there is no guarantee that malloc ever gets interrupted
> by the signal (so increasing the timeout limit does not help:
> sometimes it finishes immediately sometimes it take several
> minutes).
I think we can count the total delivered signals instead, so the run
time is more predictable. I can write a patch.
> the second one can break make check: kernel side task
> accounting is broken and even though no more than 100 threads
> are alive at a time the cgroup task limit can be hit (even
> if that's >20000 tasks) and then all fork/clone fails so
> make check cannot continue and test results are lost.
Is this with a current kernel? We haven't seen this in a while, after
encountering it rather persistently.
Maybe this should be an xtest then, with a comment explaining why?
Thanks,
Florian