I'll re-run the test and send you a list. Thank you!
-- Davide 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 >> >> Thanks! >> >> -- >> Davide _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
