tst-getaddrinfo4 failure with glibc-2.18

Allin Cottrell cottrell@wfu.edu
Thu Aug 15 15:18:00 GMT 2013


On Wed, 14 Aug 2013, Carlos O'Donell wrote:

> On 08/14/2013 04:25 PM, Allin Cottrell wrote:
>> On Wed, 14 Aug 2013, Allin Cottrell wrote:
>>
>>> On Wed, 14 Aug 2013, Carlos O'Donell wrote:
>>>
>>>> On Wed, Aug 14, 2013 at 12:26 PM, Allin Cottrell <cottrell@wfu.edu> wrote:
>>>>> I've just built glibc-2.18 on an i686 system with gcc-4.8.1. Under "make
>>>>> check" I'm getting a failure on tst-getaddrinfo4, and I'm wondering if
>>>>> that's anything to get excited about.
>>>>>
>>>>> The file tst-getaddrinfo4.out reads as follows:
>>>>>
>>>>> SUCCESS getaddrinfo(service=NULL, family=0, flags=0): Unknown error: Success
>>>>> SUCCESS getaddrinfo(service=NULL, family=0, flags=32): Unknown error:
>>>>> Success
>>>>> SUCCESS getaddrinfo(service=NULL, family=2, flags=0): Unknown error: Success
>>>>> SUCCESS getaddrinfo(service=NULL, family=10, flags=0): Unknown error:
>>>>> Success
>>>>> FAIL getaddrinfo(service=http, family=0, flags=0): Servname not supported
>>>>> for ai_socktype: Success
>>>>> FAIL getaddrinfo(service=http, family=0, flags=32): Servname not supported
>>>>> for ai_socktype: Success
>>>>> FAIL getaddrinfo(service=http, family=2, flags=0): Servname not supported
>>>>> for ai_socktype: Success
>>>>> FAIL getaddrinfo(service=http, family=10, flags=0): Servname not supported
>>>>> for ai_socktype: Success
>>>>
>>>> Any failure is something to get excited about. An i686 build should
>>>> have no failures in the testsuite.
>>>>
>>>> You'll have to dig into the test to see exactly what it expects and
>>>> what is failing.
>>>
>>> Can you suggest a place to start digging? I've tried googling the error message + glibc [...]
>>
>> Sorry, kinda silly question. I've started looking at the code for
>> this test (a new one, I see) and trying to understand what it's
>> doing.
>
> You want to look at glibc/posix/tst-getaddrinfo4.c.
>
> Reading up on the related bug is probably a good idea.
>
> The bug is referenced in the test, and you can find it
> in the sourceware bugzilla e.g. http://sourceware.org/bugzilla/.

Thanks. The bug seems to concern the error code returned by 
getaddrinfo() under some conditions (the code not being 
posixly correct).

I tried running the (new) test program in question under glibc 
2.17 and it failed in the same way as in the 2.18 build tree. 
Since I've had no practical problems with glibc 2.17 (also 
built from source myself) I thought it was probably OK to 
ignore the failure, and I installed my 2.18 build.

I suspect it's unrelated to getaddrinfo(), but I got some 
nasty stuff going on with 2.18 -- many desktop components 
started segfaulting. I've now dropped back to 2.17 and things 
are working again.

>From the boot with glibc 2.18 this is the sort of thing 
journalctl was showing:

Aug 15 09:57:37 waverley kernel: Linux version 3.10.7 
(root@waverley) (gcc version 4.8.1 (GCC) ) #1 SMP PREEMPT Thu 
Aug 15 08:00:09 EDT 2013
Aug 15 09:57:37 waverley kernel: Command line: 
BOOT_IMAGE=dev001:\EFI\elilo\vmlinuz-3.10.7 root=/dev/sda5 
rootfstype=ext4 net.ifnames=0 ro
[...]

Aug 15 09:58:10 waverley kernel: traps: panel-1-places[397] 
general protection ip:f6e5b23b sp:ffa51fe8 error:0 in 
libc-2.18.so[f6d34000+1a4000]
Aug 15 09:58:10 waverley kernel: traps: xfdesktop[329] general 
protection ip:f662223b sp:ff8231a8 error:0 in 
libc-2.18.so[f64fb000+1a4000]
Aug 15 09:58:10 waverley kernel: traps: tumblerd[351] general 
protection ip:f739623b sp:ff9e0988 error:0 in 
libc-2.18.so[f726f000+1a4000]
Aug 15 09:58:11 waverley kernel: traps: gvfs-mtp-volume[466] 
general protection ip:f72b4535 sp:ffa5514c error:0 in 
libc-2.18.so[f718d000+1a4000]
Aug 15 09:58:11 waverley kernel: traps: gvfsd-trash[486] 
general protection ip:f739623b sp:ffce7f9c error:0 in 
libc-2.18.so[f726f000+1a4000]

--
Allin Cottrell
Department of Economics
Wake Forest University, NC



More information about the Libc-help mailing list