On Mon, Jun 12, 2017 at 02:14:19PM +0100, Peter Maydell wrote:
On 7 June 2017 at 18:54, Daniel P. Berrange <address@hidden> wrote:
The following changes since commit 0db1851becbefe3e50cfc03776fb1f75817376af:
Merge remote-tracking branch 'remotes/vivier/tags/m68k-for-2.10-pull-request'
into staging (2017-06-07 11:56:00 +0100)
are available in the git repository at:
git://github.com/berrange/qemu tags/pull-sockets-2017-06-07-1
for you to fetch changes up to 8dd2c27927b93aa352c43e8f0b9437f85d2f5f55:
tests: add functional test validating ipv4/ipv6 address flag handling
(2017-06-07 17:15:08 +0100)
----------------------------------------------------------------
Merge sockets 2017/06/07 v1
----------------------------------------------------------------
Hi; I'm afraid this ran into 'make check' problems:
On OSX and FreeBSD:
GTESTER check-qtest-i386
ERROR:/Users/pm215/src/qemu-for-merges/tests/test-sockets-proto.c:825:void
test_listen(const void *): assertion failed: (data->ipv6 != 0)
GTester: last random seed: R02Sc21fa7784ab13d0fd3274d86c5a52367
**
ERROR:/Users/pm215/src/qemu-for-merges/tests/test-sockets-proto.c:825:void
test_listen(const void *): assertion failed: (data->ipv6 != 0)
GTester: last random seed: R02Sdf653a63e8d9a5d03bfadb49122f3e9a
Ok, it appears that getaddrinfo() returns different results for "localhost"
on FreeBSD/OSX, compared to Linux. Linux returns IPv4 first, then IPv6,
while FreeBSD/OSX return IPv6 first then IPv4. The sockets code is working
correctly, but the unit test is not seeing the expected results, since its
data tables are expecting the Linux behaviour. Not sure how I'll fix this
yet, perhaps I'll just #ifdef __linux__ as a temporary hack.
On the clang runtime undefined-behavior sanitizer:
GTESTER check-qtest-i386
/home/petmay01/linaro/qemu-for-merges/qapi/qapi-visit-core.c:139:12:
runtime error: load of value 254, which is not a valid value for type
'bool'
(ditto for check-qtest-ppc64, x86_64
GTESTER check-qtest-ppc64
/home/petmay01/linaro/qemu-for-merges/qapi/qapi-visit-core.c:139:12:
runtime error: load of value 254, which is not a valid value for type
'bool'
[snip]
This usually means "forgot to initialize a bool". May or may not
be the same bug in both cases...
Yes, this was a unit test bug using g_new instead of g_new0
Regards,
Daniel