+1 On deleting the lldb-mi tests and increasing the timeout.
On Wed, 14 Mar 2018 at 02:27, Jim Ingham <jing...@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
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev