Bug 43681 - glibc v2.2.2 fails some self-tests
glibc v2.2.2 fails some self-tests
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-06-06 01:44 EDT by Steve Snyder
Modified: 2007-04-18 12:33 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-06-20 19:26:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Error msgs from failed compile of test-stdio (4.57 KB, text/plain)
2001-06-06 23:44 EDT, Steve Snyder
no flags Details

  None (edit)
Description Steve Snyder 2001-06-06 01:44:38 EDT
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:
Always

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

    a. ivh /mnt/cdrom/SRPMS/glibc-2.2.2.10.src.rpm
    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:

    ~/math/test-double
    ~/math/test-ldouble
    ~/math/test-ildoubl
    ~/math/test-idouble
    ~/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 04:32:52 EDT
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
bug.
Comment 2 Steve Snyder 2001-06-06 23:44:04 EDT
Created attachment 20536 [details]
Error msgs from failed compile of test-stdio
Comment 3 Steve Snyder 2001-06-06 23:44:53 EDT
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:

    ~/c_stubs/test-stdio

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 08:26:25 EDT
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 ()
 #endif
 }

+const char *
+__gconv_lookup_alias (const char *name)
+{
+  return name;
+}
+
 strong_alias (__gconv_OK,
              __gconv_close_transform);
 strong_alias (__gconv_OK,
Comment 5 Need Real Name 2001-06-20 19:26:41 EDT
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-2.2.2.11.src.rpm
because this package requires the same patch.

FYI.


Comment 6 Jakub Jelinek 2001-07-23 11:34:06 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.