test failure on x86 architecture for ip6_pton

[hasufell]

I tried both in an x86 virtualbox and compiled with "-m32" on an amd64 host:
https://gist.github.com/hasufell/0f50726e556d842104ab

Doesn't happen on amd64 architecture for me.

[saghul]

Does it fail on the same machine without specifying "-m 32"?

[hasufell]

Does it fail on the same machine without specifying "-m 32"?

Nope.

[mtorromeo]

Same here, I'm holding off updating the archlinux package I am maintaining due to this test failing on x86.

[saghul]

@mtorromeo are you also compiling with -m 32 or is it a 32bit machine?

[mtorromeo]

I'm compiling for i686-pc-linux-gnu inside a clean 32bit chroot from a x86_64 host system.

[saghul]

Can you folks try #1295 ? I could reproduce it and this patch fixed it.

[mtorromeo]

@saghul nope, still failing like before

`ip6_pton` failed: exit code 134
Output from process `ip6_pton`:
Assertion failed in test/test-ip6-addr.c on line 133: 0 == uv_inet_pton(AF_INET6, "fe80:0:0:0:2acf:daff:1.2.3.4" "%en1", &addr)

[saghul]

Doh. I'm unable to reproduce the failure. This used to fail on OSX, and this patch fixes it (or so it seems!), used to fail on 32 bit Linux, but doesn't happen either (for me) :-/

Can you please tell me how to reproduce this step by step? Thanks!

[mtorromeo]

This is the PKGBUILD for archlinux which contains the automated step-by-step instructions: https://gist.github.com/mtorromeo/a2269b0bec1a63034cff

You can try it yourself if you have an archlinux environment at your disposal

Either way its pretty self-explanatory:

• files in the source=() array are downloaded and extracted
• the functions are executed in the following order:
  • prepare()
  • build()
  • check()
  • package()

The check() step fails as reported, only on i686.

[saghul]

I couldn't reproduce it myself, but the jenkins bildbots could. I force pushed the PR, can you please take the patch and test again? Thanks!

[mtorromeo]

It failed again

[saghul]

Thanks for testing @mtorromeo. Unfortunately I'm out of ideas. I cannot reproduce it myself, and while the Jenkins machines apparently could, the last version of the patch makes tests pass again :-/

[hasufell]

The patch from #1295 doesn't work for me either.

[saghul]

@hasufell how did you compile libuv?

[mtorromeo]

Maybe gcc 4.9 has something to do with it?

$> gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.9-20140507/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-cloog-version-check --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --disable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 4.9.0 20140507 (prerelease) (GCC)

[hasufell]

Nope, it is about optimization level, I am checking which one.

[hasufell]

All of them are affected for me (Os, O1, O2, O3).

[saghul]

Fixes on #1295 landed on master. Thanks a lot for the help guys!