libuv: Test failures on Alpine bot in CI

The following tests have been failing consistently in the alpine bot in the ci:

not ok 31 - tty_pty
# exit code 134
# Output from process `tty_pty`:
# Assertion failed in test/test-tty.c on line 369: 0 == uv_tty_init(&loop, &master_tty, master_fd, 0)

not ok 101 - udp_multicast_join6
# exit code 134
# Output from process `udp_multicast_join6`:
# Assertion failed in test/test-udp-multicast-join6.c on line 135: r == 0

not ok 112 - pipe_getsockname_abstract
# exit code 134
# Output from process `pipe_getsockname_abstract`:
# Assertion failed in test/test-pipe-getsockname.c on line 191: memcmp(buf, abstract_pipe, sizeof abstract_pipe) == 0

not ok 192 - poll_bad_fdtype
# exit code 134
# Output from process `poll_bad_fdtype`:
# Assertion failed in test/test-poll.c on line 607: 0 != uv_poll_init(uv_default_loop(), &poll_handle, fd)

not ok 194 - socket_buffer_size
# exit code 134
# Output from process `socket_buffer_size`:
# Assertion failed in test/test-socket-buffer-size.c on line 52: value == 10000 || value == 20000

I tried to reproduce the issue in an alpine docker image on a Debian Jessie host with no luck. All the tests passed correctly.

After getting access to the Alpine bot and with the help of @jbergstroem we found out that some syscalls were behaving differently on the docker image than on the bot and that the reason for that could be that the docker image is using the Debian kernel whereas the Alpine bot, that is running on a SmartOS LX Zone, uses whatever kernel it uses, and they behave differently.

As an example: in the poll_bad_fdtype test, polling on a directory is not supported on Linux, but apparently is supported on the Alpine running on the SmartOS. To confirm this theory, we started a Debian Jessie instance on a SmartOS zone, and the same tests failed (well, all of them but the tty_pty).

In case this explanation is correct, should we do something about it? The options I can think of:

• Do nothing. It’s a tier 2 platform so it doesn’t have to be run on the CI.
• Ask the nodejs build group to move the bot to some other container platform that behaves correctly.

/cc @libuv/collaborators @libuv/sunos