<div dir="ltr">Aha, in that case, it definitely sounds like increasing the timeout is in order. I would still go for something less than 30 minutes, but I don't care about that much. I may just export LLDB_TEST_TIMEOUT locally to lower it if tests taking long to time out start bugging me.<div><br></div><div>BTW, do you know which test is that? Is it one of the tests I have listed in one of the previous emails?</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, 13 Mar 2018 at 14:52, Davide Italiano <<a href="mailto:dccitaliano@gmail.com">dccitaliano@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Mar 13, 2018 at 3:30 AM, Pavel Labath <<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>> wrote:<br>
> I think we should get some data before pulling numbers out of our sleeves.<br>
> If we can get some numbers on the slowest machine that we have around, then<br>
> we should be able to specify the timeout as some multiple of the slowest<br>
> test. For example, for me the slowest test takes around 110 seconds. The<br>
> timeout is 4 minutes (~ 2x) and I don't get tests timing out. How long does<br>
> the slowest test take for you? If we set the timeout as 3x or 4x that<br>
> number, we should create a sufficiently large buffer and still avoid<br>
> half-hour waits.<br>
><br>
<br>
The longest test takes over 300 seconds. This is a late 2013 Mac Pro,<br>
so, definitely not the newest machine out there (but also something<br>
fairly high spec).<br>
For the archives, my conf is something like; cmake -GNinja ../llvm &&<br>
ninja check-lldb<br>
<br>
Thanks!<br>
<br>
--<br>
Davide<br>
</blockquote></div>