ID: 38757
Updated by: [EMAIL PROTECTED]
Reported By: davidb at pins dot net
-Status: Assigned
+Status: Feedback
Bug Type: Apache related
Operating System: Solaris 8
PHP Version: 5.1.6
Assigned To: dmitry
New Comment:
You have tested the old version, pool(..., 1000) means 1 second
timeout. In new version you should have 5 seconds.
Previous Comments:
------------------------------------------------------------------------
[2006-09-18 21:29:16] davidb at pins dot net
One other thing which we noticed - if we take our sample
(which breaks) and change the multipart-form to a regular
form, the problem does not occur.
This is weird, and I have no idea how it may bear into the
problem. It may be a red herring of some sort. Any ideas on
the next step in debugging?
------------------------------------------------------------------------
[2006-09-15 03:51:35] davidb at pins dot net
Greetings.
I tried with the latest 5.2 (downloaded today). It doesn't seem to
make a difference. The poll() still exits with 0, then proceeds to
read everything in anyway. Heres the truss, with timestamps this
time:
94.3878 accept(0, 0xFFBEDC78, 0xFFBEDBC4, 1) = 4
AF_UNIX name =
94.3880 fcntl(0, F_SETLK, 0xFFBEDC50) = 0
typ=F_UNLCK whence=SEEK_SET start=0 len=0
sys=4290697848 pid=2086536
95.3952 poll(0xFFBEDB18, 1, 1000) = 0
fd=4 ev=POLLRDNORM rev=0
95.3959 shutdown(4, 1, 1) = 0
recv(4, 0xFFBEDC50, 8, 0) (sleeping...)
signotifywait() (sleeping...)
lwp_sema_wait(0xFD70DE60) (sleeping...)
sema type: USYNC_THREAD count = 0
103.4047 recv(4, "0101\001\0\b\0\0", 8, 0) = 8
103.4050 recv(4, "\001\0\0\0\0\0\0", 8, 0) = 8
103.4051 recv(4, "0104\001\016\0\0", 8, 0) = 8
103.4051 recv(4, "0E06 C O N T E N", 8, 0) = 8
103.4052 recv(4, " T _ L E N G T H", 8, 0) = 8
103.4053 recv(4, " 1 2 8 9 9 00104", 8, 0) = 8
103.4054 recv(4, "\001\0 E\0\0\f 7", 8, 0) = 8
103.4055 recv(4, " C O N T E N T _", 8, 0) = 8
103.4055 recv(4, " T Y P E m u l t", 8, 0) = 8
....
I guess the big question is why is poll exiting with 0 when there's a
pile of valid data?
David.
------------------------------------------------------------------------
[2006-09-13 13:08:06] [EMAIL PROTECTED]
The bug should be fixed in CVS HEAD and PHP_5_2.
Please verify and close or reopen bug.
I just incrised the data waiting timeout from 1 to 5 sec.
It is good idea to use SO_ACCEPTFILTER instead of timeout, but it is
avbailable only on BSD.
------------------------------------------------------------------------
[2006-09-12 16:03:41] davidb at pins dot net
A few other quick comments:
- Perl + CGI::Fast hasn't reported any of these problems
- This is only affecting a small subset of users, but those users tend
to continue to have the problems recur
- The users with recurring problems will sometimes suddenly, and
without warning, start working again
I strongly suspect some odd network interaction, but I'm not entirely
sure where to dig deeper just yet.
The FastCGI PHP instance is linked as a local UNIX socket:
FastCgiServer /export/httpd/DOMAINS/host.forward.com/cgi-bin/php
-port 9050
AddHandler php-fastcgi .php
<Location /cgi-bin/php>
SetHandler fastcgi-script
</Location>
Action php-fastcgi /cgi-bin/php
There are several other vhosts that use teh FastCgiExternalServer
directive. We are using the PHP process manager to front-end the PHP
work threads by setting PHP_FCGI_CHILDREN.
------------------------------------------------------------------------
[2006-09-12 15:50:36] davidb at pins dot net
Greetings.
Is the poll() timing out, even though it appeared to get all of the
data in fd4? Or, is there additional data that isn't getting passed on
for some reason? I can send the entire truss if you'd like.
We're running Apache 1.3.33, Solaris 8, on a dual-processor SPARC. I
believe it's the 2.4.2 FastCGI. I do note that the read() that a valid
post gets is different.
In a good truss:
poll(0xFFBED8F0, 1, 1000) = 1
read(4, "0101\001\0\b\0\0", 8) = 8
read(4, "\001\0\0\0\0\0\0", 8) = 8
read(4, "0104\001\015\0\0", 8) = 8
read(4, 0xFFBDD918, 21) = 21
0E05 C O N T E N T _ L E N G T H 6 1 0 1 5
read(4, "0104\001\0 V\0\0", 8) = 8
read(4, 0xFFBDD918, 86) = 86
\f H C O N T E N T _ T Y P E m u l t i p a r t / f o r m - d a t
a ; b o u n d a r y = - - - - - - - - - - - - - - - - - - - -
- - - - - - - 1 9 1 9 4 1 1 2 6 6 2 0 5 9 7
read(4, "0104\001\0 =\0\0", 8) = 8
read(4, 0xFFBDD918, 61) = 61
\r . D O C U M E N T _ R O O T / e x p o r t / h t t p d / D O M
A I N S / t e s t 2 . f o r w a r d . c o m / h t d o c s
The poll seems to return with a 1, but the data that's read in is the
same. Is there something about the submit from different users that
would cause the poll() to return differently? I have network snoops,
as well.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/38757
--
Edit this bug report at http://bugs.php.net/?id=38757&edit=1
