On Feb 27, 2013, at 1:17 PM, Axel Rau <Axel.Rau@Chaos1.DE> wrote:
Am 26.02.2013 um 00:39 schrieb glyph@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