Bug 43681
| Summary: | glibc v2.2.2 fails some self-tests | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Steve Snyder <swsnyder> | ||||
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Aaron Brown <abrown> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 7.1 | CC: | fweimer | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| 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: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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. Created attachment 20536 [details]
Error msgs from failed compile of test-stdio
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.
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,
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. 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. |
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.