Bug 43681

Summary: glibc v2.2.2 fails some self-tests
Product: [Retired] Red Hat Linux Reporter: Steve Snyder <swsnyder>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact: Aaron Brown <abrown>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: fweimer
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-06-20 23:26:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
Error msgs from failed compile of test-stdio none

Description Steve Snyder 2001-06-06 05:44:38 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5 i686; en-US; 0.7) Gecko/20010510

Description of problem:
glibc v2.2.2 fails the following self-tests: test-double, test-ldouble,
test-ildoubl, test-idouble, tst-aio2, tst-aio4.

How reproducible:

Steps to Reproduce:
0. In a fresh installation of RedHat Linux v7.1, build glibc v2.2.2:

    a. ivh /mnt/cdrom/SRPMS/glibc-
    b. rpm -bc /usr/src/redhat/SPECS/glibc.spec

1. After building completes, run the self tests:

    a. cd /usr/src/redhat/BUILD/glibc-2.2.2/build-i386-linux
    b. make check

2. After each failure, rerun "make check" to continue the self-testing.
(The tests already run will be skipped.)  By the time all the tests have
been run there will have been 6 failures:

    ~/rt/tst-aio2        - "Timed out: killed the child process"
    ~/rt/tst-aio4        - "Didn't expect signal from child: got 'File size
limit exceeded'"


Actual Results:  Six of the self-tests failed.

Expected Results:  All tests should be successful.

Additional info:

0.  This behavior is seen on a newly-installed v7.1 system.  All the
development tools used in the build are those found on the v7.1
distribution binary RPM CDs.

1.  This is on an AMD K6-2-based system.  I don't know what architecture
(i386/i486/i586/i686) the RHL v7.1 installer selected when installing the
arch-specific kernel and glibc packages.

2.  Building from an unmodified "glibc.spec" causes the compiler switch
"-march=i386" to be used by default.  Modifying the spec file to build with
"-march=k6" instead shows no change in the results of the self-testing.

3.  No compiler/linker errors (but plenty of warnings) are seen either
while building the glibc binaries or while building the test programs.

4.  A request: If it is the tests themselves that are bad (rather than a
given glibc library function and/or compiler code generation), then please
remove the test from the suite.  Having false info (test results) is worse
than having no info at all.  Thank you.

5.  I'm going to give this bug a severity of "Normal" because I don't know
if these test failures really indicate a problem or not.  If they represent
actual failure of the tested glibc functionality, then it a Severe problem.
 If the problem is just poor tests, then the actual severity is trivial.

Comment 1 Jakub Jelinek 2001-06-06 08:32:52 UTC
I do glibc make check pretty often, and with rare exceptions it succeeds all,
worst case the aio test fail from time to time with the SIGXFSZ signal (need
to investigate it still).
From your report, I understand you're running on some AMD, right?
It is possible the FPU in AMD chips is even more crappy than in Intel chips.
Can you:
a) try more recent glibc, such as the one from rawhide
b) if the math tests still fail, tell me exactly which tests failed and how
many ulps they were off (just read build-*-linux/math/test-*.out for failed
tests). If they are off by one or two ulps from the expected precision, then
it is well possible it is result of FPU issues and no matter what they are
not serious. If it is off by millions of ulps, then it is certainly a serious

Comment 2 Steve Snyder 2001-06-07 03:44:04 UTC
Created attachment 20536 [details]
Error msgs from failed compile of test-stdio

Comment 3 Steve Snyder 2001-06-07 03:44:53 UTC
Regarding hardware: I hadn't considered that it might be a hardware problem.
Since you mentioned it, I checked AMD's errata.  For my processor (CPU="Mobile
K6-2", Model=8, Stepping=0x0C) no math-related bugs are documented.  (There were
a couple of bugs in the handling of the FPU status register in prior steppings.)

Regarding software: running the "make check" self-tests on gcc-2.2.3-10 (from
Rawhide), I got past the double-precision tests without failure.  I did get a
new error, though:


Whereas the double-precision self-tests would build OK then give erroneous
output, the "test-stdio" test won't build at all.  I am attaching file text
"make-check.out" which shows the errors seen in the build.  The problem appears
to be numerous symbol conflicts.

Please let me know if you need any addional info.

Comment 4 Jakub Jelinek 2001-06-07 12:26:25 UTC
The c_stubs failure is not as severe as you might thing (do you use -lc_stubs?).
That's why ignored it so far, the fix is trivial though:
--- c_stubs/gconv_stubs.c.jj    Thu Aug  3 15:21:39 2000
+++ c_stubs/gconv_stubs.c       Thu Jun  7 07:25:38 2001
@@ -46,6 +46,12 @@ __gconv_NOCONV ()

+const char *
+__gconv_lookup_alias (const char *name)
+  return name;
 strong_alias (__gconv_OK,
 strong_alias (__gconv_OK,

Comment 5 Need Real Name 2001-06-20 23:26:41 UTC
Regarding the earlier comments:

1. The math problems are reported as max.ulp=n, ulp=n+1.  If that's not a cause
for concern, then I'm not concerned.

Regarding those last comments:

1. Do I use -lc_stubs?  Beats me.  I use whatever the spec file calls for and
RHL v7.1 supports.

2. This "trivial" fix apparently did not make it into glibc-
because this package requires the same patch.


Comment 6 Jakub Jelinek 2001-07-23 15:34:06 UTC
The tst-aio* failures should be gone since mid June, c_stubs fix is in
since glibc-2.2.3-12, having maximum error 1 ulp more than it is allowed to
by libm-.*ulps isn't something which you should worry about.