The following reply was made to PR os-solaris/3467; it has been noted by GNATS.

From: "Christopher W. Curtis" <[EMAIL PROTECTED]>
To: Marc Slemko <[EMAIL PROTECTED]>
Cc: Apache bugs database <[EMAIL PROTECTED]>
Subject: Re: os-solaris/3467: Broken client connections not detected
Date: Wed, 02 Dec 1998 11:34:37 -0500

 Marc Slemko wrote:
 > 
 > On Tue, 1 Dec 1998, Christopher W. Curtis wrote:
 > 
 > > be it. PHP does not patch anything in Apache, and I am 99.997% sure
 > > that PHP is using the Apache-style read/write calls (PHP implements
 > 
 > Yea, but it can do it wrong.
 
 Ahh.  Hmm.
 
 > If it is inside an ap_soft_timeout then php needs to be checking
 > r->connection->aborted and the return value from the write functions.
 > 
 > There are many many modules that do handle this properly.
 
 Okay ... here's a message I composed yesterday:
 
 ---
 I purposefully broke a connection and truss'd it.  The first write after
 the connection was broken gives no error.  The second write gives:
 
 write(6, " < f o n t c o l o r =".., 198)       Err#32 EPIPE
     Received signal #13, SIGPIPE [ignored]
 alarm(0)                                        = 0
 sigaction(SIGALRM, 0xEFFFE780, 0xEFFFE830)      = 0
 sigprocmask(SIG_BLOCK, 0xEFFFE820, 0xEFFFE810)  = 0
 alarm(10)                                       = 0
 sigsuspend(0xEFFFE800)          (sleeping...) 
 
 ... and then it continues to try to write as the page continues to spit
 out data.  The server-status handler shows two active processes writing,
 where there should only be one.  Contrary to what I said before, there
 are no open ports associated with the child that ignores SIGPIPE and
 continues to run.  Another truss gives:
 
 read(7, "05 C h r i s\t 9 1 2 5 6".., 55)       = 55
 read(7, "01\0\0\n", 4)                          = 4
 read(7, "FE", 1)                                = 1
 alarm(0)                                        = 0
 sigaction(SIGALRM, 0xEFFFE780, 0xEFFFE830)      = 0
 sigprocmask(SIG_BLOCK, 0xEFFFE820, 0xEFFFE810)  = 0
 alarm(10)                                       = 0
 sigsuspend(0xEFFFE800)          (sleeping...)
 
 That first line is data that *should* be written to the browser.  It
 looks like Apache has given up trying to write anything entirely.  Maybe
 this is a better indication of what is going on.  Maybe the signal
 handler sets some flag that isn't fully qualified?  Just guessing...
 
 Thanks again,
 Christopher
 -- 
 Oh My God!  They Killed init!  You Bastards!!

Reply via email to