[Bug network/15272] getaddrinfo() returns EAI_SYSTEM with AF_UNSPEC and SOCK_STREAM on ARM

["dan at coneharvesters dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=15272

Dan Fandrich <dan at coneharvesters dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dan at coneharvesters dot com

--- Comment #12 from Dan Fandrich <dan at coneharvesters dot com> ---
I'm able to reproduce this on x86_64 consistently on a couple of machines under
Linux 3.10.24 using the neon test suite. Steps to reproduce:

curl -O http://www.webdav.org/neon/neon-0.29.6.tar.gz
tar xaf neon-0.29.6.tar.gz
cd neon-0.29.6
./configure --without-ssl --without-egd --without-pakchois --without-gssapi
--without-libproxy --without-libxml2 --without-expat --without-zlib
--disable-webdav
make
make check

And then, as needed,

cd test
./request

Test 68 is the first one that fails, then several others.

This is using glibc 2.18 and gcc 4.8.2. I've tried creating a simple test case
that reproduces the same getaddrinfo calls as done in the test suite, but it's
not sufficient to cause the failure. Changing the order of tests is enough to
work around the problem, so it's clearly some subtle internal state that needs
to be set up for the failure to occur.

The failing getaddrinfo() calls being done in the test suite are equivalent to:

        hints.ai_socktype = SOCK_STREAM;
        hints.ai_flags = AI_ADDRCONFIG;
        hints.ai_family = AF_UNSPEC;
        errnum = getaddrinfo("localhost", NULL, &hints, &res);

Either of the following two patches is sufficient to work around the problem
and allow the test suite to pass. Changing the order of getaddrinfo() calls:

--- neon-0.29.6/test/request.c.orig     2014-01-05 06:36:01.124005697 +0000
+++ neon-0.29.6/test/request.c  2014-01-05 06:37:28.859996470 +0000
@@ -2397,8 +2397,6 @@
     T(fail_long_header),
     T(fail_on_invalid),
     T(read_timeout),
-    T(fail_lookup),
-    T(fail_double_lookup),
     T(fail_connect),
     T(proxy_no_resolve),
     T(fail_chunksize),
@@ -2422,5 +2420,7 @@
     T(socks_v4_proxy),
     T(send_length),
     T(socks_fail),
+    T(fail_lookup),
+    T(fail_double_lookup),
     T(NULL)
 };

Or using AF_INET instead of AF_UNSPEC:

--- neon-0.29.6/src/ne_socket.c.orig        2014-01-04 14:42:09.665502390 +0000
+++ neon-0.29.6/src/ne_socket.c     2014-01-05 00:56:28.287272839 +0000
@@ -925,8 +925,9 @@
     {
 #ifdef USE_GAI_ADDRCONFIG /* added in the RFC3493 API */
         hints.ai_flags = AI_ADDRCONFIG;
-        hints.ai_family = AF_UNSPEC;
+        hints.ai_family = AF_INET; //AF_UNSPEC;
         addr->errnum = getaddrinfo(hostname, NULL, &hints, &addr->result);
+        hints.ai_family = ipv6_disabled ? AF_INET : AF_UNSPEC;
 #else
         hints.ai_family = ipv6_disabled ? AF_INET : AF_UNSPEC;
        addr->errnum = getaddrinfo(hostname, NULL, &hints, &addr->result);

-- 
You are receiving this mail because:
You are on the CC list for the bug.