autoconf-patches
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]