This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: tst-getaddrinfo4 failure with glibc-2.18


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]