[CalendarServer-dev] Exception in recvfd --was: Re: continuing work on FreeBSD ports
glyph at twistedmatrix.com
Wed Feb 27 14:21:31 PST 2013
On Feb 27, 2013, at 1:17 PM, Axel Rau <Axel.Rau at Chaos1.DE> wrote:
> Am 26.02.2013 um 00:39 schrieb glyph at twistedmatrix.com:
>> There are no calls to 'sendmsg()' in this trace, that I can see:
>> glyph at rem:~/Downloads/2013.02.21$ grep 'sendmsg(' debug.trace
>> [Error: 1]
>> glyph at rem:~/Downloads/2013.02.21$ grep 'recvmsg(' debug.trace
>> 50395: 3.830958519 recvmsg(0x19,0x7fffffffab30,0x0,0x0,0x1010,0x7fffffffa760) = 1 (0x1)
>> 50395: 3.945254507 recvmsg(0x1b,0x7fffffffab30,0x0,0x0,0x1010,0x7fffffffa760) = 1 (0x1)
>> glyph at rem:~/Downloads/2013.02.21$
> Yes, as explained earlier, my patch prevents sendmsg from seing
I ... don't think I understood the earlier explanation.
>> Can you include the master process as well?
> I think, it's included (50395).
Sorry, I meant, can you include a dtruss of the master process as well, rather than instrumenting with a debug patch?
At this point it might be more effort than it's worth, since I think I know what's going on.
>>> This version hangs after the accept() instead of segfaulting.
>> Hangs *after* the accept(), not *in* the accept()?
> As 50395 continues after the accept(), 'hang' is the wrong word.
> I just see no http answer on the client side.
Right, and that makes sense, since the FD never properly gets to the worker process (which is where all the actually HTTP traffic happens).
> I think we should focus on the original problem
This is all related, I'm still concerned about the original problem :).
More information about the calendarserver-dev