[lfs-dev] Test failures in something close to current LFS

Ken Moffat zarniwhoop at ntlworld.com
Sun Feb 22 18:22:11 PST 2015


On Fri, Jan 30, 2015 at 10:59:17PM +0000, Ken Moffat wrote:
> On Thu, Jan 29, 2015 at 12:23:56AM +0000, Ken Moffat wrote:
> > 
> > gcc: 125 unexpected failures in g++, 658 in gcc, 22 in libstdc++
> > instead of the usual handful of failures.  The last time I saw those
> > sorts of numbers was a little while before my AmigaOne expired.
> > 
>  I wonder if some of it was because my tmpfs for /tmp was too small.
> I thought I was using 6GB, but I was on my 7.6 system when I set
> that up, the November system I used to build the new one was still
> using only 2GB for /tmp.
> 
>  I've now rebuilt gcc on the completed system, again using only 2GB
> for the tmpfs.  This time, the results were a little better - only
> 83 unexpected failures in gcc, and 42 in g++, none in libstdc++.
> In both cases, I used -j4.
> 
[ cut the context there! ]

 I did further testing, and never managed to pin down what was
causing the varying number of failures (and I could not see any
evidence for what the tests actually returned or should have
returned - I'm sure it was there somewhere, but I do not really want
to become more acquainted with gcc's testsuite.  At one time, using
-j1 looked as if it would help, but in the end it was still
unreliable.  In particular, building on a real spinning disk did NOT
seem to help.  All that repeated testing was x86_64.

 On Friday night I built 7.7 i686 in qemu.  Because I could not work
out how to make the box suspend when the qemu session had completed,
I built with -j1.  It looked pretty good, just 4 failures in g++.

 Tonight I've been rerunning the tests on a completed system, still
in qemu.  It occurred to me that some of the failures might be
sub-architecture specific.  So, for the first run I continued with
the 'kvm64' CPU and used -j4 : g++ was the same, but gcc now
reported 31 unexpected failures, and all bar two were in gomp.

 In other words, either the failures are random, or using -j4
instead of -j1 for the tests causes more failures.

 Then I decided to run with -j4 and --cpu=host (this is a Phenom
x4).  For gcc, 149 unexpected failures, apparently all in
gcc.dg/c99-typespec-1.c.  For g++, the same 4 failures as before
(asan/asan_test.C and 3 from pr61160-3.C).

 Even running with -j4, this takes a significant amount of time, I
don't think I can justify spending more time looking at different
qemu host values and playing with -j1 or -j4 for the tests when the
box is supposed to be building 7.7 x86_64 for itself on bare metal.  There
is also a possibility that there are one or more races in the tests,
and results might be random.  But I think I will change my script to
use -j1 for the tests.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.


More information about the lfs-dev mailing list