This is an archive of the discontinued LLVM Phabricator instance.

[lit] Try to remove the flakeyness of `shtest-timeout.py` and `googletest-timeout.py`.
AbandonedPublic

Authored by delcypher on Oct 4 2020, 2:42 PM.

Details

Summary

The tests previously relied on the short.py and FirstTest.subTestA
script being executed on a machine within a short time window (1 or 2
seconds). While this "seems to work" it can fail on resource constrained
machines. We could bump the timeout a little bit (bumping it too
much would mean the test would take a long time to execute) but it wouldn't
really solve the problem of the test being prone to failures.

Instead this patch tries to make the tests less flakeys by no longer
running short.py and FirstTest.subTestA. The trade-off here is that
this means we no longer test if it is possible for a test to complete
execution when a timeout is set.

This seems like the right trade-off right now because debugging this
flakey test is not a good use of engineering time.

Diff Detail

Event Timeline

delcypher created this revision.Oct 4 2020, 2:42 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 4 2020, 2:42 PM
delcypher requested review of this revision.Oct 4 2020, 2:42 PM
dblaikie added inline comments.Oct 4 2020, 6:38 PM
llvm/utils/lit/tests/Inputs/googletest-timeout/DummySubDir/OneTest.py
20–27

If these (subTestB and subTestC) do the same thing - should one of them be removed to avoid redundancy?

(and/or was the intent to keep the not-slow test, A (& one of only B or C) - if it is sufficiently less flakey?)

yln added a comment.Oct 5 2020, 10:15 AM

Flaky tests are the worst! Thanks for working on this :)

I think the principled way here would be to have two separate lit invocations for timeout fail/pass:

not lit --timeout=1 infinite_hang.py
# Will hang for 1 second, then aborted by timeout.

lit --timeout=999 short.py
# Will take however long it takes to do `short.py`, then pass. 999 just means "very long timeout"
# This will be immediate on normal hosts, and whatever time it takes on resource constrained hosts.

Or am I missing something?

In D88807#2312194, @yln wrote:

Flaky tests are the worst! Thanks for working on this :)

I think the principled way here would be to have two separate lit invocations for timeout fail/pass:

not lit --timeout=1 infinite_hang.py
# Will hang for 1 second, then aborted by timeout.

lit --timeout=999 short.py
# Will take however long it takes to do `short.py`, then pass. 999 just means "very long timeout"
# This will be immediate on normal hosts, and whatever time it takes on resource constrained hosts.

Or am I missing something?

You're not missing anything. This is a very good idea and I wish I had thought of it. I'll update the patch to take the approach you've outlined.

llvm/utils/lit/tests/Inputs/googletest-timeout/DummySubDir/OneTest.py
20–27

Probably but @yln 's comments mean that I might do things very differently.

delcypher abandoned this revision.Oct 7 2020, 5:24 PM

This patch is superseded by https://reviews.llvm.org/D89020.

llvm/utils/lit/tests/Inputs/googletest-timeout/DummySubDir/OneTest.py