<div dir="ltr">Ping again. We're seeing this on several aarch64 bots, what can we do about it?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 23 Nov 2020 at 21:19, David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</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">Ping on this - Dan, any chance you could take a look here?<br>
<br>
On Mon, Nov 9, 2020 at 1:48 PM Arthur Eubanks <<a href="mailto:aeubanks@google.com" target="_blank">aeubanks@google.com</a>> wrote:<br>
><br>
> Another case: <a href="http://lab.llvm.org:8011/#/builders/43/builds/810" rel="noreferrer" target="_blank">http://lab.llvm.org:8011/#/builders/43/builds/810</a><br>
> shtest-timeout.py seems to be fairly flaky on the clang-cmake-aarch64-quick bot: <a href="http://lab.llvm.org:8011/#/builders/43" rel="noreferrer" target="_blank">http://lab.llvm.org:8011/#/builders/43</a>, I get notifications from it fairly often<br>
><br>
> On Thu, Oct 22, 2020 at 7:15 PM David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> Looks like there might still be some issues with the timeout tests? <a href="http://lab.llvm.org:8011/#/builders/126/builds/226/steps/13/logs/FAIL__lit___shtest-timeout_py" rel="noreferrer" target="_blank">http://lab.llvm.org:8011/#/builders/126/builds/226/steps/13/logs/FAIL__lit___shtest-timeout_py</a><br>
>><br>
>> On Sun, Oct 4, 2020 at 2:44 PM Dan Liew <<a href="mailto:dan@su-root.co.uk" target="_blank">dan@su-root.co.uk</a>> wrote:<br>
>>><br>
>>> > > One thing we could do to remove fragility in the test is to remove the<br>
>>> > > running of `short.py` in the test. This is only invoked to check that<br>
>>> > > it's possible for a command to run to completion in the presence of a<br>
>>> > > fixed timeout. If we can live without testing that part (i.e. we only<br>
>>> > > test that a timeout can be reached) then the test should be much more<br>
>>> > > robust.<br>
>>> ><br>
>>> > If you're on board with that, it's a tradeoff I think is probably<br>
>>> > reasonable from a test coverage V reliability V development time<br>
>>> > tradeoff.<br>
>>><br>
>>> Sorry for the delay here. I've put a patch up for review that goes<br>
>>> with this approach: <a href="https://reviews.llvm.org/D88807" rel="noreferrer" target="_blank">https://reviews.llvm.org/D88807</a><br>
>><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>