<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 14, 2019 at 2:47 PM Jim Ingham <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Aug 14, 2019, at 1:41 PM, Adrian Prantl via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
> <br>
> <br>
> <br>
>> On Aug 14, 2019, at 11:26 AM, Adrian McCarthy via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
>> <br>
>> A recent change is causing several LLDB tests on Windows to fail and several more to time out, which I intend to look into.<br>
>> <br>
>> 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., <a href="http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/7819/steps/test/logs/stdio" rel="noreferrer" target="_blank">http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/7819/steps/test/logs/stdio</a>)<br>
>> <br>
>> Is there a reason why the timeouts are set that long? What would be a reasonable value?<br>
> <br>
> I recently increased/unified several internal timeouts throughout LLDB (<a href="https://reviews.llvm.org/D60340" rel="noreferrer" target="_blank">https://reviews.llvm.org/D60340</a>) in reaction to bots failing randomly on heavily used machines, particularly when ASAN is enabled, which can cause surprisingly long delays.<br>
> <br>
> 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.<br>
<br>
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</blockquote><div><br></div><div>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.</div><div><br></div><div>There are also many tests actually failing on Windows. It's time consuming to bisect when the timeouts add 10 minutes to every step.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> - 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.<br>
<br>
Jim<br>
<br>
> <br>
> -- adrian<br>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div></div>