[lldb-dev] increase timeout for tests?

[Pavel Labath via lldb-dev]

+1 On deleting the lldb-mi tests and increasing the timeout.



On Wed, 14 Mar 2018 at 02:27, Jim Ingham <jingham at apple.com> wrote:

> It is unfortunate that we have to set really long test timeouts because we
> are timing the total Test class run, not the individual tests.  It is
> really convenient to be able to group similar tests in one class, so they
> can reuse setup and common check methods etc.  But if we're going to have
> to push the timeouts to something really long because these tests get
> charged incorrectly, which makes this strategy artificially less desirable.
>
> When we spawn a dotest.py to run each test file, the runner that is doing
> the timeout hasn't ingested the test class, so it can't do something
> reasonable like count the number of tests and multiply that into the
> timeout to get the full test timeout.  I tried to hack around this but I
> wasn't successful at getting hold of the test configuration in the runner
> so you could figure out the number of tests there.  If somebody more
> familiar with the test harness than I am can see a way to do that, that
> seems like a much better way to go.
>
> But if we can't do that, then we can increase the overall timeout.  Though
> we might want to override that with LLDB_TEST_TIMEOUT and set it to
> something lower on the bots.
>
>
Counting the test methods would be a bit tricky, I believe. I think that a
slightly more feasible solution (although it would still require some
rearchitecting) would be to base the timeout on the last message received
from the "inferior" dotest instance. Each dotest sub-process opens up a
socket to communicate the test results to the master process. We could use
this as a liveness indicator, and base the timeout on the time elapsed
since the last message. This is still a bit tricky because right now the
timeout logic is in a completely different place than the communication
code, but this could be fixed (if someone feels adventurous enough).

cheers,
pl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180314/1a064f23/attachment.html>