This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: tst-getaddrinfo4 failure with glibc-2.18
- From: Allin Cottrell <cottrell at wfu dot edu>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: libc-help at sourceware dot org
- Date: Tue, 10 Sep 2013 09:22:28 -0400 (EDT)
- Subject: Re: tst-getaddrinfo4 failure with glibc-2.18
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LNX dot 2 dot 03 dot 1308141222580 dot 1968 at wfu dot edu> <CAE2sS1jURE7KJCMbLqkZeQHLz5N5LV2ygY8CXBWosL0+NfRY8A at mail dot gmail dot com> <alpine dot LFD dot 2 dot 03 dot 1308141606420 dot 2742 at wfu dot edu> <alpine dot LFD dot 2 dot 03 dot 1308141624190 dot 3078 at wfu dot edu> <520BE867 dot 5060304 at redhat dot com> <alpine dot LNX dot 2 dot 03 dot 1308151104040 dot 652 at wfu dot edu> <alpine dot LNX dot 2 dot 03 dot 1308151234310 dot 554 at wfu dot edu> <522E011D dot 6000803 at redhat dot com>
On Mon, 9 Sep 2013, Carlos O'Donell wrote:
On 08/15/2013 12:51 PM, Allin Cottrell wrote:
I should have said: this is on a system with 64-bit kernel and 32-bit userspace. I'm seeing something that may be related at
http://www.linuxquestions.org/questions/linux-from-scratch-13/glibc-2-18-and-acroread-4175473288
I last built and installed glibc-2.17 in January, since when I've
updated gcc (4.8.1) and kernel headers (3.10.7). So I just tried the
experiment of rebuilding 2.17 under my current setup, to check that
nothing had gone screwy in the meantime in regard to my ability to
build a properly functioning glibc. Result: all OK, the system is
stable with glibc-2.17 as rebuilt today. But it's seriously unstable
with glibc-2.18 as built with the same toolchain and configure
options, namely:
../glibc-2.17/configure --build=i686-pc-linux-gnu \
--prefix=/usr --with-tls \
--disable-profile --enable-add-ons \
--enable-kernel=3.10.7
I may have said this already but I'll it bears repeating.
You should always run the testsuite. If the testsuite has any
failures you should not install glibc. You should determine the
root cause of the failures.
If you can get backtraces of your failing applications and file
a bug that would be much appreciated.
I always run the test suite and pay attention to the results.
When I first built glibc-2.18 "make check" failed on two tests:
tst-getaddrinfo4 and tst-cputimer1.
However, (a) tst-cputimer1 also failed for me with 2.17 and Linux from
Scratch remarks that it can fail due to "minor timing issues"; and (b)
tst-getaddrinfo4 is a new test with 2.18, and when I "backported" it to
2.17 it also fails there. Since 2.17 has given me trouble-free operation
for many months, I didn't regard these particular failures as
deal-blockers.
The deal-blocker was that several programs started segfaulting when I
installed 2.18 -- and so I dropped back to 2.17. But following the
suggestion from Ondřej Bílka in
https://sourceware.org/ml/libc-help/2013-08/msg00043.html
I looked at
http://www.sourceware.org/ml/libc-alpha/2013-08/msg00257.html
and tried applying the "fix" for i686 mentioned by Allan McRae, namely
reinstating the "inline" keyword (removed in glibc git on 2013-02-07) for
the function __m128i_strloadu() in sysdeps/x86_64/multiarch/strstr.c. I
then rebuilt and reinstalled 2.18 and so far nothing has segfaulted. The
specific issue with the Java runtime that I reported in
https://sourceware.org/ml/libc-help/2013-08/msg00042.html
has not recurred.
I put "fix" in scare quotes above, because the lengthy discussion
following Allan McRae's libc-alpha posting suggests that right fix is not
obvious. But as an empirical matter it "works for me". In terms of
diagnosing the problem I don't think I have anything to add to that
discussion other than this data-point: I also had crashes in
__strstr_sse42 with out-of-the-box glibc 2.18 on i686, and they've stopped
after patching strstr.c as stated.
Allin Cottrell