Am 20.02.2013 um 07:02 schrieb gl...@twistedmatrix.com: > > On Feb 19, 2013, at 1:28 PM, Axel Rau <axel....@chaos1.de> wrote: > >> Hi, >> >> the break came from finding and reading "Unix Network Programming" by >> Stevens/Fenner/Rudoff. (-; >> >> Am 14.02.2013 um 11:37 schrieb Fredrik Unger: >> >>> From the top of my head I find it strange that just 3 bytes was received. >>> If I remember correctly my tests sent more (with sendmsg). >> I think, the reason is, that *no* ancillary data is being sent: > > Like... no ancillary data is being *passed to sendmsg*? Yes. My debug print at the beginning of sendmsg always shows 0. > Or no data is being received from recvmsg? Does tracing the relevant > processes with something like strace or dtruss confirm this? What process is > being debugged here; master, worker, or both? Both, because the unpack error pointed at a platform/compatibility issue in sendmsg.c, which is used by all parts. I will try to get a trace with dtruss. > > The debug messages which you've added seem like they might be missing some > data, since they just truncate after 'return from sendmsg with', rather than > printing a string (even an empty one) after. Yes, the code was not finished. should display sendmsg_result, which was always 1. See attached diff. > >> Without ancillary data, no fd can be shipped. >> The only place where ancillary data could be provided seems to be >> twext.internet.sendfdport._SubprocessSocket.doWrite. >> I would be happy for any hint where to dig... > > Well, hrm. This code works fine on other platforms, so, one thing to check > would be to see if previous versions of the FreeBSD kernel have the same > issue. What exact versions of everything are you testing? 8.2 and 9.1. Both show same bug. > >> Axel >> PS: sendmsg.c seems to be very fragile as debug code changes >> behaviour of the system (i.e. it locks up after trying a http >> connect and does not reach point of original exception) > > This is too general of a comment to really be any use in debugging - but, > this code is extremely low-level and sensitive to any I/O that happens on its > socket. Where are your debug messages going that are disrupting things? To a file on disk. > > I *really* don't know what you mean by "does not reach point of original > exception", though. Can you elaborate? With my debug code, the master process dies immediately on connect to the web server. This does not happen, with the unmodified sendmsg.c.
> > -glyph > Axel
sendmsg.diff
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
