io::net::tcp::test::write_close_ip4 failing on OS X 10.10

[brendanzab]

These tests seem to be failing for me on OS X 10.10. I have heard on IRC that others are having this issue too. I don't know if it is a Yosemite issue - I didn't have it on 10.9. It looks like:

run: x86_64-apple-darwin/stage2/test/stdtest-x86_64-apple-darwin

running 696 tests
test ascii::tests::test_ascii_to_bytes ... ok
test ascii::tests::test_ascii_as_str ... ok
...
test io::net::pipe::tests::read_timeouts ... ok
test io::net::tcp::test::write_close_ip4 ... FAILED
test io::net::tcp::test::timeout_concurrent_read ... ok
test io::net::tcp::test::write_close_ip6 ... ok
...

---- io::net::tcp::test::write_close_ip4 stdout ----
    task 'io::net::tcp::test::write_close_ip4' panicked at 'unknown error: Protocol wrong type for socket', /Users/brendan/dev/rust/rust/src/libstd/io/net/tcp.rs:675


failures:
    io::net::tcp::test::write_close_ip4

test result: FAILED. 633 passed; 1 failed; 62 ignored; 0 measured

[brendanzab]

@erickt says he has reduced it here: https://gist.github.com/erickt/ac1f35e20834aa5d1972

[brendanzab]

It also fails sometimes on write_close_ip6.

[erickt]

I've extracted that test case here: https://gist.github.com/erickt/ac1f35e20834aa5d1972. To reproduce it, I can run rustc --test test.rs && while ./test --nocapture; do sleep 0.2; done

[erickt]

I am also on OSX 10.10.

[alexcrichton]

I have a feeling the test in this case is just probably wrong, it's somewhat sketchy already with a loop around the call to write. I added some explicit synchronization and it seems to work ok on yosemite now. I'll make a PR soon.

[erickt]

I think there's actually a bug here that we must be tripping over. I've reduced this bug down to the nearly c-ish https://gist.github.com/erickt/fea1b81ac3b5cf8056ac, which seems reasonable at first glance, and may end up in some users code. You're right that we (or the OSX 10.10 kernel?) are probably missing a lock somewhere, but it'd be nice to figure out exactly what's going on.

[erickt]

I've done some archeological work, and the underlying syscall is sendto, which is returning the EPROTOTYPE errno. I also found that the OSX XNU is on github, and it seems like this might be a valid error. I've found a couple functions that mention both send and EPROTOTYPE:

https://github.com/opensource-apple/xnu/blob/bb7368935f659ada117c0889612e379c97eb83b3/bsd/netinet/tcp_usrreq.c#L927-L951
https://github.com/opensource-apple/xnu/blob/10.10/bsd/kern/uipc_usrreq.c#L408
https://github.com/opensource-apple/xnu/blob/10.10/bsd/kern/uipc_usrreq.c#L501

If I'm interpret this code correctly, it appears that Apple may have allowed some network operations to be interruptible. So if a sendto gets interrupted and the socket gets closed, it can return a EPROTOTYPE. What you're supposed to do to handle this errno, but if you retry the send it'll error with the more normal EPIPE.

[alexcrichton]

I believe these tests have since been removed, so closing.