I'll re-run the test and send you a list.
On Tue, Mar 13, 2018 at 9:02 AM, Pavel Labath <lab...@google.com> wrote:
> 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.
> BTW, do you know which test is that? Is it one of the tests I have listed in
> one of the previous emails?
> On Tue, 13 Mar 2018 at 14:52, Davide Italiano <dccitali...@gmail.com> wrote:
>> On Tue, Mar 13, 2018 at 3:30 AM, Pavel Labath <lab...@google.com> wrote:
>> > I think we should get some data before pulling numbers out of our
>> > sleeves.
>> > If we can get some numbers on the slowest machine that we have around,
>> > then
>> > we should be able to specify the timeout as some multiple of the slowest
>> > test. For example, for me the slowest test takes around 110 seconds. The
>> > timeout is 4 minutes (~ 2x) and I don't get tests timing out. How long
>> > does
>> > the slowest test take for you? If we set the timeout as 3x or 4x that
>> > number, we should create a sufficiently large buffer and still avoid
>> > half-hour waits.
>> The longest test takes over 300 seconds. This is a late 2013 Mac Pro,
>> so, definitely not the newest machine out there (but also something
>> fairly high spec).
>> For the archives, my conf is something like; cmake -GNinja ../llvm &&
>> ninja check-lldb
lldb-dev mailing list