tst-getaddrinfo4 failure with glibc-2.18

[Allin Cottrell]

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