ALZ (phyglos.org) wrote:
On 02/20/2016 09:49 PM, Bruce Dubbs wrote:
Bruce Dubbs wrote:
Douglas R. Reno wrote:
On Fri, Feb 19, 2016 at 3:18 PM, Bruce Dubbs <[email protected]>
wrote:
I've built the new glibc in my sandbox and will start doing a -rc2
when my
full build completes in the next hour or so.
I did look at the test failures:
XPASS: elf/tst-protected1a
XPASS: elf/tst-protected1b
FAIL: posix/tst-getaddrinfo4
FAIL: posix/tst-getaddrinfo5
Summary of test results:
2 FAIL
2401 PASS
84 XFAIL
2 XPASS
I've updated the text to add posix/tst-getaddrinfo5 to the list of
known
failures. When I look at the text we have now, I also see:
* The rt/tst-cputimer1 and rt/tst-cpuclock2 tests have been known to
fail.
The reason is not completely understood, but indications are that minor
timing issues can trigger these failures.
* The math tests sometimes fail when running on systems where the
CPU is
not a relatively new Intel or AMD processor.
* Other tests known to fail on some architectures are
malloc/tst-malloc-usable and nptl/tst-cleanupx4.
I have already removed the text about tst-protected1{a,b}.
I have not seen any of these in a long time. Should I remove them?
Are these i686 specific?
I don't think so, but I'm not sure. I can do a build on my 686 and
check,
but that wouldn't hold off proceeding with BLFS testing. I'll try to set
it up tonight and let it run to check. A full build with all tests takes
about 17 hours on that system.
Well it took 18 hours, but the 7.9-rc2 built on my 686. For glibc, I
had one additional test failure: nptl/tst-cleanupx4. That is mentioned
above.
Over here, after +3h for Ch5 and +17h for Ch6, on a Pentium M 1.6 Ghz
(i686) with 2GB RAM.
Here the results of glibc-2.23:
XPASS: elf/tst-protected1a
XPASS: elf/tst-protected1b
FAIL: nptl/tst-cleanupx4
FAIL: posix/tst-getaddrinfo4
FAIL: posix/tst-getaddrinfo5
FAIL: stdio-common/test-vfprintf
Summary of test results:
4 FAIL
2377 PASS
84 XFAIL
2 XPASS
On a Q9950 @3.4Ghz with 12 GB RAM (x86_64), expected results:
XPASS: elf/tst-protected1a
XPASS: elf/tst-protected1b
FAIL: posix/tst-getaddrinfo4
FAIL: posix/tst-getaddrinfo5
Summary of test results:
2 FAIL
2401 PASS
84 XFAIL
2 XPASS
In a VMware guest (x86_64) with 4 GB, interesting combination:
XPASS: conform/UNIX98/ndbm.h/linknamespace
XPASS: conform/XOPEN2K/ndbm.h/linknamespace
XPASS: conform/XOPEN2K8/ndbm.h/linknamespace
XPASS: conform/XPG4/ndbm.h/linknamespace
XPASS: elf/tst-protected1a
XPASS: elf/tst-protected1b
FAIL: stdio-common/test-vfprintf
Summary of test results:
1 FAIL
2402 PASS
80 XFAIL
6 XPASS
I also had a bunch of gcc test failures not in x86-64. There were 8
failures using different options with c-c++-common/asan/null-deref-1.c,
1 failure for gcc.dg/pr45352-1.c, and 1 for gcc.dg/pr63914.c. The test
failures that are in the x86_64 build, directory_iterator.cc and
recursive_directory_iterator.cc fail here too.
The only other failure I see that differs from x86-64 is:
105-inetutils-1.9.4:FAIL: ping-localhost.sh
On the physical x86_64, clean results:
=== g++ Summary ===
# of expected passes 93742
# of unexpected successes 2
# of expected failures 342
# of unsupported tests 3746
=== gcc Summary ===
# of expected passes 114783
# of expected failures 262
# of unsupported tests 1806
=== libatomic Summary ===
# of expected passes 54
=== libgomp Summary ===
# of expected passes 1617
# of unsupported tests 170
=== libitm Summary ===
# of expected passes 26
# of expected failures 3
# of unsupported tests 1
=== libstdc++ Summary ===
# of expected passes 9871
# of unexpected failures 2
# of expected failures 65
# of unsupported tests 530
The 2 unexpected failures are the same that appear on virtual x86_64:
FAIL: experimental/filesystem/iterators/recursive_directory_iterator.cc
execution test
FAIL: experimental/filesystem/iterators/directory_iterator.cc execution test
On the i686 laptop, several timeouts and up to 12 unexpected failures...
With regards 'segfaults' and 'traps' in /var/log/kern.log while testing gcc:
* on i686 there are 216 segfaults, no traps
* on physical x86_64, 138 segfaults plus 57 traps
* on virtual x86_64, 163 segfaults and 73 traps.
I'm pretty sure this is a part of testing and most, if not all, are
handled in the tests.
Hope it helps.
Yes, it does. Thanks.
The stdio-common/test-vfprintf is new to me, but I recognize everything else.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
