Re: Intermittent parallel test failures

[Bob Proulx]

Hi Ralf,

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/>
> <http://buildbot.proulx.com:9003/i686%20gnu-linux/builds/909/step-test/0>
> <http://buildbot.proulx.com:9003/amd64%20gnu-linux/builds/878/step-test/0>

Interesting...  I didn't read those in detail.  But I agree that there
is an intermitten failure in there.

> I am trying to find out
> 1) whether the exact failure on your systems is the same that I saw,
> 2) what differences there are to the system I have where I do not see
>    any failures.

I can give you ssh shell access if it would help.  Send me your ssh
rsa pub key and I will set you up.

> 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.

   find . -name '*.log'
  ./tests/instfail-java.dir/config.log
  ./tests/upc3.dir/config.log
  ./tests/java.dir/config.log
  ./tests/upc.dir/config.log
  ./config.log

I changed the test line so:

  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.

> For (2), it would be nice to know a bit more about the systems.  Which
> shell (and version) do the systems use?  Which kernel version?  Are they
> dual or uniprocessor/-core systems?  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.  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.

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.

Now we will need to let it build and look for new failures with the
new testsuite.log file in the output.

> Thanks for this very helpful service!

Glad to help!

Bob