[CalendarServer-dev] [Workaround] Re: Exception in recvfd --was: Re: continuing work on FreeBSD ports

[Axel Rau]

Am 26.02.2013 um 00:02 schrieb glyph at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: socket.h
Type: application/octet-stream
Size: 21787 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/calendarserver-dev/attachments/20130227/db2a75d1/attachment-0002.obj>
-------------- next part --------------
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sendmsg_mini.patch
Type: application/octet-stream
Size: 1620 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/calendarserver-dev/attachments/20130227/db2a75d1/attachment-0003.obj>
-------------- next part --------------

---
PGP-Key:29E99DD6  ? +49 151 2300 9283  ? computing @ chaos claudius