GNOME Bugzilla – Bug 693636
test failure: ERROR:test-linc.c:388:test_local_ipv4: assertion failed: (link_protocol_is_local (proto, saddr, saddr_len))
Last modified: 2013-02-13 02:11:17 UTC
(as reported downstream at https://bugs.gentoo.org/show_bug.cgi?id=413231) orbit-2.14.19 fails its test suite on some machines: make[3]: Entering directory `/var/tmp/portage/gnome-base/orbit-2.14.19-r1/work/ORBit2-2.14.19/linc2/test' Available protocols: { ' IPv4': 2, 16, 6, 0x0002 [s-ail] ' IPv6': 10, 28, 6, 0x0002 [s-ail] ' UNIX': 1, 110, 0, 0x0003 [-dail] } Testing 'broken' ... Testing blocking code ... buffer 512 buffer 1024 buffer 0 Testing is_local checking ... UNIX IPv4 ** ERROR:test-linc.c:388:test_local_ipv4: assertion failed: (link_protocol_is_local (proto, saddr, saddr_len)) /bin/sh: line 5: 16052 Aborted (core dumped) ${dir}$tst FAIL: test-linc This seems to be caused by a logic error in link_protocol_is_local_ipv46(); to determine whether an address is local, the function compares it to local_addr, which is obtained from getaddrinfo(link_get_local_hostname(), ...). The trouble is that depending on how the machine is set up, getaddrinfo(link_get_local_hostname(), ...) might return ipv6 addresses by default - and comparing ipv6 address with ipv4 obviously would not work. The solution is to set hints.ai_family when calling getaddrinfo().
Created attachment 235765 [details] [review] proposed patch The attached patch fixes the test suite for me.
Review of attachment 235765 [details] [review]: Why: if (proto->family == AF_INET) 387 hints.ai_family = AF_INET; And not hints.ai_family = proto->family or somesuch ? Either way - it looks fine to me; thanks for the diagnosis, the fix and submitting it here :-) !
(In reply to comment #2) > Review of attachment 235765 [details] [review]: > > Why: > > if (proto->family == AF_INET) > 387 hints.ai_family = AF_INET; > > And not hints.ai_family = proto->family or somesuch ? Because I had misread some of the following lines and thought that unconditionally setting "hints.ai_family = proto->family" might change existing semantics in the ipv6 case. But you are right, it shouldn't make a difference. Fixed version committed: http://git.gnome.org/browse/ORBit2/commit/?id=623749eb6e2a87f6a8723b68e0d224b8ea08ff60