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

[Axel Rau]

Am 20.02.2013 um 07:02 schrieb glyph at twistedmatrix.com:

> 
> On Feb 19, 2013, at 1:28 PM, Axel Rau <axel.rau at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sendmsg.diff
Type: application/octet-stream
Size: 6794 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/calendarserver-dev/attachments/20130220/b099f427/attachment.obj>
-------------- next part --------------

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