On Feb 27, 2013, at 1:17 PM, Axel Rau <axel....@chaos1.de> wrote:
>
> Am 26.02.2013 um 00:39 schrieb gl...@twistedmatrix.com:
>
>> There are no calls to 'sendmsg()' in this trace, that I can see:
>>
>> glyph@rem:~/Downloads/2013.02.21$ grep 'sendmsg(' debug.trace
>> [Error: 1]
>> glyph@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@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 :).
-glyph
_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/calendarserver-dev
