As a workaround, assuming you're running the tests with lit, you should be able to override the timeout with --max-time.
On Wed, Aug 14, 2019 at 4:15 PM Adrian McCarthy via lldb-dev <lldb-dev@lists.llvm.org> wrote: > > > > On Wed, Aug 14, 2019 at 2:47 PM Jim Ingham <jing...@apple.com> wrote: >> >> >> >> > On Aug 14, 2019, at 1:41 PM, Adrian Prantl via lldb-dev >> > <lldb-dev@lists.llvm.org> wrote: >> > >> > >> > >> >> On Aug 14, 2019, at 11:26 AM, Adrian McCarthy via lldb-dev >> >> <lldb-dev@lists.llvm.org> wrote: >> >> >> >> A recent change is causing several LLDB tests on Windows to fail and >> >> several more to time out, which I intend to look into. >> >> >> >> It appears the timeout period is set to 600 seconds (10 minutes), which >> >> seems excessive and causes the Windows build bot to spend lots of time >> >> waiting. (e.g., >> >> http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/7819/steps/test/logs/stdio) >> >> >> >> Is there a reason why the timeouts are set that long? What would be a >> >> reasonable value? >> > >> > I recently increased/unified several internal timeouts throughout LLDB >> > (https://reviews.llvm.org/D60340) in reaction to bots failing randomly on >> > heavily used machines, particularly when ASAN is enabled, which can cause >> > surprisingly long delays. >> > >> > Since the normal operation should be that no tests fail, waiting an extra >> > 10 minutes in the exceptional case that a test does fail seems more >> > desirable than the chance of a working test failing because of too-small >> > timeout. Therefore, I'd rather pick an excessively large per-test timeout >> > to be safe. >> >> This is a little pedantic, but tests that fail some assert also won't >> trigger the timeout. It should only be tests that fail by stalling > > > FYI: There are six tests stalling on Windows. They've been doing it long > enough that the bot history no longer shows the last good build and the grid > view never shows anything other than "building" because it can no longer keep > up with the rate of submissions. > > There are also many tests actually failing on Windows. It's time consuming > to bisect when the timeouts add 10 minutes to every step. > >> >> - for instance you expected to hit a breakpoint but never did - that trigger >> the timeout. That should be even less frequent that just test failures. >> >> Jim >> >> > >> > -- adrian >> > _______________________________________________ >> > lldb-dev mailing list >> > lldb-dev@lists.llvm.org >> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
