Allow cargo test to complete on OpenBSD 6.4/AMD64

[pusateri]

disable some features that aren't included in OpenBSD.

[asomers]

What's wrong with this test?

[pusateri]

I didn't try to diagnose the problem. I was just trying to get tests to pass so I could work on IP6_PKTINFO, IP_RECVIF, and IP_RECV_DSTADDR

failures:

---- sys::test_socket::test_scm_rights stdout ----
thread 'sys::test_socket::test_scm_rights' panicked at 'slice index starts at 24 but ends at 20', libcore/slice/mod.rs:1977:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

[pusateri]

This could be #999. If there's an alignment problem, off by 4 could happen.

[pusateri]

Here's a stack trace with RUST_BACKTRACE=1

failures:

---- sys::test_socket::test_scm_rights stdout ----
thread 'sys::test_socket::test_scm_rights' panicked at 'slice index starts at 24 but ends at 20', libcore/slice/mod.rs:1977:5
stack backtrace:
   0: __register_frame_info
   1: __register_frame_info
   2: __register_frame_info
   3: __register_frame_info
   4: __register_frame_info
   5: __register_frame_info
   6: __register_frame_info
   7: __register_frame_info
   8: __register_frame_info
   9: __register_frame_info
  10: __register_frame_info
  11: __register_frame_info
  12: __register_frame_info
  13: __register_frame_info
  14: __register_frame_info
  15: __register_frame_info
  16: __register_frame_info
  17: __register_frame_info
  18: __register_frame_info
  19: __register_frame_info
  20: __register_frame_info
  21: __register_frame_info
  22: __register_frame_info
  23: __register_frame_info
  24: pthread_create


failures:
    sys::test_socket::test_scm_rights

test result: FAILED. 87 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

[pusateri]

When running the test as standalone code in a main(), I got a different stack trace:

% RUST_BACKTRACE=1 cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 4.53s
     Running `target/debug/scm_rights`
thread 'main' panicked at 'slice index starts at 24 but ends at 20', libcore/slice/mod.rs:1977:5
stack backtrace:
   0: __register_frame_info
   1: __register_frame_info
   2: __register_frame_info
   3: __register_frame_info
   4: __register_frame_info
   5: __register_frame_info
   6: __register_frame_info
   7: __register_frame_info
   8: __register_frame_info
   9: __register_frame_info
  10: __register_frame_info
  11: __register_frame_info
  12: __register_frame_info
  13: __register_frame_info
  14: __register_frame_info
  15: __register_frame_info
  16: __register_frame_info
  17: __register_frame_info
  18: __register_frame_info
  19: __register_frame_info
  20: <unknown>

[asomers]

I don't think #999 is related. If anything, #999 should cause bus errors on platforms like mips that don't allow unaligned loads. This error looks more like we got some alignment stuff wrong in #648. When you encounter the bug, what is the address of the struct cmsghdr? If it's 4-byte aligned, then try putting the CmsgSpace in a Box. That should increase its alignment to 16 bytes. If that fixes the test, then we know where the problem lies.

[pusateri]

Looks 16 byte aligned to me. On the sendmsg side:

(gdb) print cmsg
Python Exception <class 'gdb.error'> That operation is not available on integers of more than 8 bytes.: 
Python Exception <class 'gdb.error'> That operation is not available on integers of more than 8 bytes.: 
$1 = nix::sys::socket::ControlMessage::ScmRights(&[i32](len: 1) = {5})
(gdb) print &cmsg
$2 = (nix::sys::socket::ControlMessage *) 0x7f7ffffea920

On the recvmsg side:

28              let mut cmsgspace: CmsgSpace<[RawFd; 1]> = CmsgSpace::new();
(gdb) n
29              let msg = recvmsg(fd2, &iov, Some(&mut cmsgspace), MsgFlags::empty()).unwrap();
(gdb) print &cmsgspace
$3 = (nix::sys::socket::CmsgSpace<[i32; 1]> *) 0x7f7ffffeaa60

[asomers]

Well, there goes that theory. Maybe cmsg_align doesn't work correctly on OpenBSD? If you could reimplement the test in C, that might reveal where any alignment errors lie.

[pusateri]

It looks like the unwrapped RecvMsg from recvmsg() is not 16 byte aligned:

Breakpoint 1, scm_rights::main::h34fb823cda0cd73f () at src/main.rs:34
34                  for cmsg in msg.cmsgs() {
(gdb) print msg
$1 = RecvMsg = {bytes = 5, cmsg_buffer = &[u8](len: 20) = {20, 0, 0, 0, 255, 
    255, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, Python Exception <class 'gdb.error'> Cannot convert value to int.: 
0}, 
  address = <error reading variable>, flags = MsgFlags = {bits = 0}}
(gdb) print &msg
$2 = (nix::sys::socket::RecvMsg *) 0x7f7fffff2838

[asomers]

So I can fix this particular error by setting align_of_cmsg_data = u32 on OpenBSD. But I don't have any theoretical reason for doing that, and it breaks the ScmTimestamp test. I think the best thing to do is to rewrite all of the cmsg code in terms of CMSG_DATA and friends, which are provided by libc.

[asomers]

Closing as a duplicate of #1000 .