[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Intermittent parallel test failures
From: |
Ralf Wildenhues |
Subject: |
Re: Intermittent parallel test failures |
Date: |
Fri, 10 Oct 2008 06:16:49 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
Hi Bob,
* Bob Proulx wrote on Fri, Oct 10, 2008 at 01:22:55AM CEST:
> Ralf Wildenhues wrote:
> > as I noted earlier in
> > <http://thread.gmane.org/gmane.comp.sysutils.autoconf.patches/5563/focus=5786>,
> > there are intermittent test failures for the parallel tests. These
> > failures also show up in the build bot output:
> > <http://buildbot.proulx.com:9003/>
> Interesting... I didn't read those in detail. But I agree that there
> is an intermitten failure in there.
> > For (1), would it be possible to include tests/testsuite.log in the
> > logged state for a failed test suite? Thanks.
>
> Does that file get removed if the check is successful? It doesn't
> seem to exist after a normal build.
Erm, it should. Could it be you're looking at Automake not Autoconf's
bot?
> make -k check || cat tests/testsuite.log
>
> Assuming that tests/testsuite.log exists when the make check fails
> then it should appear in the output now.
This won't work for Automake. But it doesn't matter. I'll ask you for
a change to Automake's testing soon anyway.
> > Also, it looks to me like the amd64
> > one prints system info that looks like it's an x86:
> > <http://buildbot.proulx.com:9003/amd64%20gnu-linux>
>
> Oops. That is a static information file and was a copy of the other
> machine created when I cloned from one to the other to set up the
> build daemon. I fixed it now.
Thanks.
> The amd64 system is a Debian Etch
> stable system on a single AMD Athlon 64 2.2 GHz Processor 3200+ with
> 1G of ram stock in all ways except for the newer autoconf required to
> bootstrap the scm version of autoconf itself.
OK, good to know.
> Note that the machines get very busy due to overlapping builds. It is
> possible that this failure only occurs when things are very bogged
> down.
That shouldn't be a problem. Well it could be, but the testsuite should
be resilient enough to cope with bogged-down systems.
To give a bit more detail: I modified the parallel test so that the race
that happens between parallel and serial execution is rather unlikely
won even on a very loaded system. OTOH we've also been seeing dropped
output in the parallel case, and that's probably what happens on your
system, too.
Cheers,
Ralf