Windows test suite timeouts

[Matt Harbison]

Mads Kiilerich wrote:
> Dirkjan Ochtman wrote, On 01/05/2013 10:40 AM:
>> On Fri, Jan 4, 2013 at 4:06 AM, Matt Harbison
>> <matt_harbison at yahoo.com> wrote:
>>> Every so often, I've noticed that some tests on Windows will take a
>>> really
>>> long time, and then timeout:
>>>
>>> $ python run-tests.py -i test-largefiles.t
>>>
>>> ERROR: c:\Users\Matt\Projects\hg\tests\test-largefiles.t timed out
>>> t
>>> Failed test-largefiles.t: timed out
>>> # Ran 1 tests, 0 skipped, 1 failed.
>> Actually, on Gentoo, test-largefiles.t and test-mq.t have been timing
>> out for a bunch of users, so I'm guessing that test's problems aren't
>> only on Windows.
>
> These tests _are_ big and will reach the timeout limit on slow or
> overloaded hardware. The timeout had to be increased on some of the
> buildbots.
>
> In both cases: Are you sure the tests really are hanging, or are they
> just too slow?
>
> /Mads

It looks like that was the problem:

   $ time python run-tests.py -t 600 test-largefiles.t
   .
   # Ran 1 tests, 0 skipped, 0 failed.

   real    3m58.038s
   user    0m0.000s
   sys     0m0.062s

I'm really surprised it is that high above the 3 minute default timeout, 
since it works so consistently until it fails consistently.  This is an 
8 core laptop @ 1.87 Ghz, 3 idle during the test and 4Gb of RAM free.

But this pretty much tracks with what I've seen- happens after a long 
uptime, clears on reboot, and ran 3 times in a row with the raised 
timeout (and both of your patches applied).  I'm not sure why it works 
in a Linux virtual box on the same machine, or why the full .t.err is 
generated, but at least we got to the bottom of it.

Thanks for the help.

--Matt