Travis builds failing

Austin Seipp austin at
Mon Jun 1 19:42:59 UTC 2015

On Mon, Jun 1, 2015 at 2:34 PM, Joachim Breitner
<mail at> wrote:
> Hi,
> Am Montag, den 01.06.2015, 14:26 -0500 schrieb Austin Seipp:
>> I don't think there's any built-in way to do that in the current
>> testsuite infrastructure, other than setting THREADS=1, which, if it
>> isn't set already, would probably push us back over the Travis build
>> limit.
> we are running validate with CPU=2, which I believe translates to

It's actually the opposite - if you check ./validate, CPU=2 translates
to THREAD=3! The reasoning is 'CPUS' is the number of physical cores
you have, and it adds 1 to saturate all your cores, while the extra
thread gets scheduled during I/O overlap on the underlying disk from
the other threads, overall improving throughput. Normally it's a win
on a completely un-contested machine, as some overlap exists.

> But we never had memory problems before, and 3GB is still quite a bit.
> Are we sure that there is no bug here? Or is our official requirement
> now above 3GB?

Well, it's possible there's something else lurking here. Maybe the
merge of D913 caused things to spike for some reason, during the
cleanup? Possible there was an error in the refactoring. But given
that the buildbot only has 3GB and executed (in essence) with
THREADS=3, I'm almost certain that it's just because they all ran at
once, and the OOM killed them. We may have just gotten lucky?

Also, Thomas has alerted me that the testsuite actually has an option
called `high_memory_usage` which will serialize the tests and run them
one at a time. So actually, that can work as a solution too!

> Greetings,
> Joachim
> --
> Joachim “nomeata” Breitner
>   mail at joachim-breitner.de
>   Jabber: nomeata at  • GPG-Key: 0xF0FBF51F
>   Debian Developer: nomeata at
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at


Austin Seipp, Haskell Consultant
Well-Typed LLP,

More information about the ghc-devs mailing list