Am 26.02.2013 um 00:02 schrieb gl...@twistedmatrix.com: > It seems to me that you *have* found the real bug; 64-bit FreeBSD is sending > along 4 extra bytes of ... stuff ... for each file descriptor. The question > is, why? Does 32-bit FreeBSD do the same thing? Is there reference > documentation that explains this? Not that I know of. socket.h attached. > The standards are, sadly, pretty opaque as to how SCM_RIGHTS actually works. Right. I have done one last trial to look (only) at the data put in the tuple at the end of recvmsg. This patch (attached) runs flawlessly (does not disturb sendmsg).
Output from the debug log in recvfd: recvfd: socketfd=26, data="TCP", flags=0x0x0L, cmsg_level=0x0xffffL, cmsg_type=0x0x1L, packedFD="0x0d00000000000000" recvfd: socketfd=26, data="TCP", flags=0x0x0L, cmsg_level=0x0xffffL, cmsg_type=0x0x1L, packedFD="0x0d000000460dd5b5" recvfd: socketfd=26, data="TCP", flags=0x0x0L, cmsg_level=0x0xffffL, cmsg_type=0x0x1L, packedFD="0x0f00000000000000" recvfd: socketfd=26, data="TCP", flags=0x0x0L, cmsg_level=0x0xffffL, cmsg_type=0x0x1L, packedFD="0x0f00000000000000" recvfd: socketfd=26, data="TCP", flags=0x0x0L, cmsg_level=0x0xffffL, cmsg_type=0x0x1L, packedFD="0x0f00000000000000" recvfd: socketfd=28, data="SSL", flags=0x0x0L, cmsg_level=0x0xffffL, cmsg_type=0x0x1L, packedFD="0x0d00000000000000" recvfd: socketfd=28, data="SSL", flags=0x0x0L, cmsg_level=0x0xffffL, cmsg_type=0x0x1L, packedFD="0x0d00000000000000" recvfd: socketfd=28, data="SSL", flags=0x0x0L, cmsg_level=0x0xffffL, cmsg_type=0x0x1L, packedFD="0x0f00000000000001" recvfd: socketfd=28, data="SSL", flags=0x0x0L, cmsg_level=0x0xffffL, cmsg_type=0x0x1L, packedFD="0x0f00000000036c6f" recvfd: socketfd=28, data="SSL", flags=0x0x0L, cmsg_level=0x0xffffL, cmsg_type=0x0x1L, packedFD="0x0f00000001feffff" and corresponding lines from debug files in /tmp (produced by patch below in sendmsg): recvmsg/ancillary/entry: fd=0x1a, level=0xffff, type=0x1, data=0xd, len=20, sizeof cmsghdr=12 recvmsg/ancillary/entry: fd=0x1a, level=0xffff, type=0x1, data=0xd, len=20, sizeof cmsghdr=12 recvmsg/ancillary/entry: fd=0x1a, level=0xffff, type=0x1, data=0xf, len=20, sizeof cmsghdr=12 recvmsg/ancillary/entry: fd=0x1a, level=0xffff, type=0x1, data=0xf, len=20, sizeof cmsghdr=12 recvmsg/ancillary/entry: fd=0x1a, level=0xffff, type=0x1, data=0xf, len=20, sizeof cmsghdr=12 recvmsg/ancillary/entry: fd=0x1c, level=0xffff, type=0x1, data=0xd, len=20, sizeof cmsghdr=12 recvmsg/ancillary/entry: fd=0x1c, level=0xffff, type=0x1, data=0xd, len=20, sizeof cmsghdr=12 recvmsg/ancillary/entry: fd=0x1c, level=0xffff, type=0x1, data=0xf, len=20, sizeof cmsghdr=12 recvmsg/ancillary/entry: fd=0x1c, level=0xffff, type=0x1, data=0xf, len=20, sizeof cmsghdr=12 recvmsg/ancillary/entry: fd=0x1c, level=0xffff, type=0x1, data=0xf, len=20, sizeof cmsghdr=12 data, as being put into the tuple at end of recvmsd does have a size of 20-12=8, which should be 4. Why? Axel
socket.h
Description: Binary data
sendmsg_mini.patch
Description: Binary data
--- PGP-Key:29E99DD6 ☀ +49 151 2300 9283 ☀ computing @ chaos claudius
_______________________________________________ calendarserver-dev mailing list calendarserver-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-dev
