Ask a Question related to PHP Bugs, Design and Development.
-
davidb at pins dot net #1
#38757 [NEW]: MultiPart Form Uploads fail with FastCGI
From: davidb at pins dot net
Operating system: Solaris 8
PHP version: 5.1.6
PHP Bug Type: Apache related
Bug description: MultiPart Form Uploads fail with FastCGI
Description:
------------
Greetings.
I'm currently observing a reproducible version of bug #26647 in the PHP
5.1 train. For a subset of users running mostly Mac but some PC browsers,
the PHP process unceremoniously exists witout comment when the form is
POST'ed. A truss of the PHP FastCGI process shows PHP reading in the text
(incidently, it's also pointed out a performance issue where php's doing a
read() of 8 bytes at a time from the FastCGI stream instead of 8kB at at a
time, but I digress). The problem appears to go away when I switch to a
non-FastCGI version.
The broken users are broken consistently - it would be possible (and easy)
to gdb trace it and see why it's exiting. Here's the start/end of the
truss:
accept(0, 0xFFBEDA50, 0xFFBED99C, 1) = 4
fcntl(0, F_SETLK, 0xFFBEDA28) = 0
poll(0xFFBED8F0, 1, 1000) = 0
shutdown(4, 1, 1) = 0
recv(4, "0101\001\0\b\0\0", 8, 0) = 8
recv(4, "\001\0\0\0\0\0\0", 8, 0) = 8
recv(4, "0104\001\015\0\0", 8, 0) = 8
recv(4, "0E05 C O N T E N", 8, 0) = 8
recv(4, " T _ L E N G T H", 8, 0) = 8
recv(4, " 8 3 5 1 90104\0", 8, 0) = 8
recv(4, "01\0 d\0\0\f V C", 8, 0) = 8
recv(4, " O N T E N T _ T", 8, 0) = 8
recv(4, " Y P E m u l t i", 8, 0) = 8
recv(4, " p a r t / f o r", 8, 0) = 8
recv(4, " m - d a t a ; ", 8, 0) = 8
recv(4, " b o u n d a r y", 8, 0) = 8
recv(4, " m L b O u N d A", 8, 0) = 8
(many many lines)
recv(4, " r Y - -\r\n0105", 8, 0) = 8
recv(4, "\001\0\0\0\0", 8, 0) = 6
recv(4, 0xFFBEDA28, 8, 0) = 0
close(4) = 0
fcntl(0, F_SETLKW, 0xFFBEDA28) = 0
accept(0, 0xFFBEDA50, 0xFFBED99C, 1) (sleeping...)
Bam. Goodbye. No error, no nothing.
Reproduce code:
---------------
<html>
<head>
</head>
<body>
<form method="post" action="response.php" enctype="multipart/form-data">
<input name="test" type="file">
<input name="submit" value="submit" type="submit" />
</form>
</body>
</html>
Expected result:
----------------
The response.php should work - note, however, that php never even attempts
to open the response.php file, which is just a trivial "file uploaded"
message, no attempt to save.
Actual result:
--------------
See above truss - php just exits.
--
Edit bug report at [url]http://bugs.php.net/?id=38757&edit=1[/url]
--
Try a CVS snapshot (PHP 4.4): [url]http://bugs.php.net/fix.php?id=38757&r=trysnapshot44[/url]
Try a CVS snapshot (PHP 5.2): [url]http://bugs.php.net/fix.php?id=38757&r=trysnapshot52[/url]
Try a CVS snapshot (PHP 6.0): [url]http://bugs.php.net/fix.php?id=38757&r=trysnapshot60[/url]
Fixed in CVS: [url]http://bugs.php.net/fix.php?id=38757&r=fixedcvs[/url]
Fixed in release: [url]http://bugs.php.net/fix.php?id=38757&r=alreadyfixed[/url]
Need backtrace: [url]http://bugs.php.net/fix.php?id=38757&r=needtrace[/url]
Need Reproduce Script: [url]http://bugs.php.net/fix.php?id=38757&r=needscript[/url]
Try newer version: [url]http://bugs.php.net/fix.php?id=38757&r=oldversion[/url]
Not developer issue: [url]http://bugs.php.net/fix.php?id=38757&r=support[/url]
Expected behavior: [url]http://bugs.php.net/fix.php?id=38757&r=notwrong[/url]
Not enough info: [url]http://bugs.php.net/fix.php?id=38757&r=notenoughinfo[/url]
Submitted twice: [url]http://bugs.php.net/fix.php?id=38757&r=submittedtwice[/url]
register_globals: [url]http://bugs.php.net/fix.php?id=38757&r=globals[/url]
PHP 3 support discontinued: [url]http://bugs.php.net/fix.php?id=38757&r=php3[/url]
Daylight Savings: [url]http://bugs.php.net/fix.php?id=38757&r=dst[/url]
IIS Stability: [url]http://bugs.php.net/fix.php?id=38757&r=isapi[/url]
Install GNU Sed: [url]http://bugs.php.net/fix.php?id=38757&r=gnused[/url]
Floating point limitations: [url]http://bugs.php.net/fix.php?id=38757&r=float[/url]
No Zend Extensions: [url]http://bugs.php.net/fix.php?id=38757&r=nozend[/url]
MySQL Configuration Error: [url]http://bugs.php.net/fix.php?id=38757&r=mysqlcfg[/url]
davidb at pins dot net Guest
-
#39123 [NEW]: upload_tmp_dir with trailing slash in open_basedir causes uploads to fail
From: phpbugs at thequod dot de Operating system: Ubuntu Linux PHP version: 5CVS-2006-10-11 (CVS) PHP Bug Type: Safe... -
#38757 [Opn->Fbk]: MultiPart Form Uploads fail with FastCGI
ID: 38757 Updated by: tony2001@php.net Reported By: davidb at pins dot net -Status: Open +Status: ... -
Large file uploads fail after 6.1 to 7.0.1 upgrade
After upgrading CF from 6.1 to 7.0.1 users are getting a "Cannot find server or DNS Error Internet Explorer" error as soon as they try to upload a... -
file upload form enctype="multipart/form-data
I'm upload a file using cffile upload and that seems to work fine except I need to use enctype="multipart/form-data on the form side. This isn't a... -
multipart/form-data
Have a form that I want users to be able to both upload a file and fill out some regular text input boxes then submit all together. I have the... -
davidb at pins dot net #2 #38757 [Fbk->Opn]: MultiPart Form Uploads fail with FastCGI
ID: 38757
User updated by: davidb at pins dot net
Reported By: davidb at pins dot net
-Status: Feedback
+Status: Open
Bug Type: Apache related
Operating System: Solaris 8
PHP Version: 5.1.6
New Comment:
Well, I tried with the latest 5.2b snapshot, and now it's broken for my
PC at home also. Appears to be the identical problem - php just
silently stops processing after it reads in the POST data, closes the
socket, and then waits for the next request, throwing a 500 server
error.
Please.
Previous Comments:
------------------------------------------------------------------------
[2006-09-08 22:09:08] [email]tony2001@php.net[/email]
Please try using this CVS snapshot:
[url]http://snaps.php.net/php5.2-latest.tar.gz[/url]
For Windows:
[url]http://snaps.php.net/win32/php5.2-win32-latest.zip[/url]
------------------------------------------------------------------------
[2006-09-08 22:04:15] davidb at pins dot net
Description:
------------
Greetings.
I'm currently observing a reproducible version of bug #26647 in the PHP
5.1 train. For a subset of users running mostly Mac but some PC
browsers, the PHP process unceremoniously exists witout comment when
the form is POST'ed. A truss of the PHP FastCGI process shows PHP
reading in the text (incidently, it's also pointed out a performance
issue where php's doing a read() of 8 bytes at a time from the FastCGI
stream instead of 8kB at at a time, but I digress). The problem
appears to go away when I switch to a non-FastCGI version.
The broken users are broken consistently - it would be possible (and
easy) to gdb trace it and see why it's exiting. Here's the start/end
of the truss:
accept(0, 0xFFBEDA50, 0xFFBED99C, 1) = 4
fcntl(0, F_SETLK, 0xFFBEDA28) = 0
poll(0xFFBED8F0, 1, 1000) = 0
shutdown(4, 1, 1) = 0
recv(4, "0101\001\0\b\0\0", 8, 0) = 8
recv(4, "\001\0\0\0\0\0\0", 8, 0) = 8
recv(4, "0104\001\015\0\0", 8, 0) = 8
recv(4, "0E05 C O N T E N", 8, 0) = 8
recv(4, " T _ L E N G T H", 8, 0) = 8
recv(4, " 8 3 5 1 90104\0", 8, 0) = 8
recv(4, "01\0 d\0\0\f V C", 8, 0) = 8
recv(4, " O N T E N T _ T", 8, 0) = 8
recv(4, " Y P E m u l t i", 8, 0) = 8
recv(4, " p a r t / f o r", 8, 0) = 8
recv(4, " m - d a t a ; ", 8, 0) = 8
recv(4, " b o u n d a r y", 8, 0) = 8
recv(4, " m L b O u N d A", 8, 0) = 8
(many many lines)
recv(4, " r Y - -\r\n0105", 8, 0) = 8
recv(4, "\001\0\0\0\0", 8, 0) = 6
recv(4, 0xFFBEDA28, 8, 0) = 0
close(4) = 0
fcntl(0, F_SETLKW, 0xFFBEDA28) = 0
accept(0, 0xFFBEDA50, 0xFFBED99C, 1) (sleeping...)
Bam. Goodbye. No error, no nothing.
Reproduce code:
---------------
<html>
<head>
</head>
<body>
<form method="post" action="response.php"
enctype="multipart/form-data">
<input name="test" type="file">
<input name="submit" value="submit" type="submit" />
</form>
</body>
</html>
Expected result:
----------------
The response.php should work - note, however, that php never even
attempts to open the response.php file, which is just a trivial "file
uploaded" message, no attempt to save.
Actual result:
--------------
See above truss - php just exits.
------------------------------------------------------------------------
--
Edit this bug report at [url]http://bugs.php.net/?id=38757&edit=1[/url]
davidb at pins dot net Guest
-
tony2001@php.net #3 #38757 [Opn->Asn]: MultiPart Form Uploads fail with FastCGI
ID: 38757
Updated by: [email]tony2001@php.net[/email]
Reported By: davidb at pins dot net
-Status: Open
+Status: Assigned
Bug Type: Apache related
Operating System: Solaris 8
PHP Version: 5.1.6
-Assigned To:
+Assigned To: dmitry
New Comment:
Dmitry, could you plz check it out?
Previous Comments:
------------------------------------------------------------------------
[2006-09-09 02:05:01] davidb at pins dot net
Well, I tried with the latest 5.2b snapshot, and now it's broken for my
PC at home also. Appears to be the identical problem - php just
silently stops processing after it reads in the POST data, closes the
socket, and then waits for the next request, throwing a 500 server
error.
Please.
------------------------------------------------------------------------
[2006-09-08 22:09:08] [email]tony2001@php.net[/email]
Please try using this CVS snapshot:
[url]http://snaps.php.net/php5.2-latest.tar.gz[/url]
For Windows:
[url]http://snaps.php.net/win32/php5.2-win32-latest.zip[/url]
------------------------------------------------------------------------
[2006-09-08 22:04:15] davidb at pins dot net
Description:
------------
Greetings.
I'm currently observing a reproducible version of bug #26647 in the PHP
5.1 train. For a subset of users running mostly Mac but some PC
browsers, the PHP process unceremoniously exists witout comment when
the form is POST'ed. A truss of the PHP FastCGI process shows PHP
reading in the text (incidently, it's also pointed out a performance
issue where php's doing a read() of 8 bytes at a time from the FastCGI
stream instead of 8kB at at a time, but I digress). The problem
appears to go away when I switch to a non-FastCGI version.
The broken users are broken consistently - it would be possible (and
easy) to gdb trace it and see why it's exiting. Here's the start/end
of the truss:
accept(0, 0xFFBEDA50, 0xFFBED99C, 1) = 4
fcntl(0, F_SETLK, 0xFFBEDA28) = 0
poll(0xFFBED8F0, 1, 1000) = 0
shutdown(4, 1, 1) = 0
recv(4, "0101\001\0\b\0\0", 8, 0) = 8
recv(4, "\001\0\0\0\0\0\0", 8, 0) = 8
recv(4, "0104\001\015\0\0", 8, 0) = 8
recv(4, "0E05 C O N T E N", 8, 0) = 8
recv(4, " T _ L E N G T H", 8, 0) = 8
recv(4, " 8 3 5 1 90104\0", 8, 0) = 8
recv(4, "01\0 d\0\0\f V C", 8, 0) = 8
recv(4, " O N T E N T _ T", 8, 0) = 8
recv(4, " Y P E m u l t i", 8, 0) = 8
recv(4, " p a r t / f o r", 8, 0) = 8
recv(4, " m - d a t a ; ", 8, 0) = 8
recv(4, " b o u n d a r y", 8, 0) = 8
recv(4, " m L b O u N d A", 8, 0) = 8
(many many lines)
recv(4, " r Y - -\r\n0105", 8, 0) = 8
recv(4, "\001\0\0\0\0", 8, 0) = 6
recv(4, 0xFFBEDA28, 8, 0) = 0
close(4) = 0
fcntl(0, F_SETLKW, 0xFFBEDA28) = 0
accept(0, 0xFFBEDA50, 0xFFBED99C, 1) (sleeping...)
Bam. Goodbye. No error, no nothing.
Reproduce code:
---------------
<html>
<head>
</head>
<body>
<form method="post" action="response.php"
enctype="multipart/form-data">
<input name="test" type="file">
<input name="submit" value="submit" type="submit" />
</form>
</body>
</html>
Expected result:
----------------
The response.php should work - note, however, that php never even
attempts to open the response.php file, which is just a trivial "file
uploaded" message, no attempt to save.
Actual result:
--------------
See above truss - php just exits.
------------------------------------------------------------------------
--
Edit this bug report at [url]http://bugs.php.net/?id=38757&edit=1[/url]
tony2001@php.net Guest
-
dmitry@php.net #4 #38757 [Asn->Fbk]: MultiPart Form Uploads fail with FastCGI
ID: 38757
Updated by: [email]dmitry@php.net[/email]
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:
From the strace log I see: PHP FastCGI server accepts connection and
waits 1 sec (in pool()) for any input from HTTP client. It doesn't get
any data in a second and does save connection close.
Could you describe your environment: CPU speed, WebServer, fastcgi
plugin, fastcgi configuraion...
Previous Comments:
------------------------------------------------------------------------
[2006-09-09 21:09:16] [email]tony2001@php.net[/email]
Dmitry, could you plz check it out?
------------------------------------------------------------------------
[2006-09-09 02:05:01] davidb at pins dot net
Well, I tried with the latest 5.2b snapshot, and now it's broken for my
PC at home also. Appears to be the identical problem - php just
silently stops processing after it reads in the POST data, closes the
socket, and then waits for the next request, throwing a 500 server
error.
Please.
------------------------------------------------------------------------
[2006-09-08 22:09:08] [email]tony2001@php.net[/email]
Please try using this CVS snapshot:
[url]http://snaps.php.net/php5.2-latest.tar.gz[/url]
For Windows:
[url]http://snaps.php.net/win32/php5.2-win32-latest.zip[/url]
------------------------------------------------------------------------
[2006-09-08 22:04:15] davidb at pins dot net
Description:
------------
Greetings.
I'm currently observing a reproducible version of bug #26647 in the PHP
5.1 train. For a subset of users running mostly Mac but some PC
browsers, the PHP process unceremoniously exists witout comment when
the form is POST'ed. A truss of the PHP FastCGI process shows PHP
reading in the text (incidently, it's also pointed out a performance
issue where php's doing a read() of 8 bytes at a time from the FastCGI
stream instead of 8kB at at a time, but I digress). The problem
appears to go away when I switch to a non-FastCGI version.
The broken users are broken consistently - it would be possible (and
easy) to gdb trace it and see why it's exiting. Here's the start/end
of the truss:
accept(0, 0xFFBEDA50, 0xFFBED99C, 1) = 4
fcntl(0, F_SETLK, 0xFFBEDA28) = 0
poll(0xFFBED8F0, 1, 1000) = 0
shutdown(4, 1, 1) = 0
recv(4, "0101\001\0\b\0\0", 8, 0) = 8
recv(4, "\001\0\0\0\0\0\0", 8, 0) = 8
recv(4, "0104\001\015\0\0", 8, 0) = 8
recv(4, "0E05 C O N T E N", 8, 0) = 8
recv(4, " T _ L E N G T H", 8, 0) = 8
recv(4, " 8 3 5 1 90104\0", 8, 0) = 8
recv(4, "01\0 d\0\0\f V C", 8, 0) = 8
recv(4, " O N T E N T _ T", 8, 0) = 8
recv(4, " Y P E m u l t i", 8, 0) = 8
recv(4, " p a r t / f o r", 8, 0) = 8
recv(4, " m - d a t a ; ", 8, 0) = 8
recv(4, " b o u n d a r y", 8, 0) = 8
recv(4, " m L b O u N d A", 8, 0) = 8
(many many lines)
recv(4, " r Y - -\r\n0105", 8, 0) = 8
recv(4, "\001\0\0\0\0", 8, 0) = 6
recv(4, 0xFFBEDA28, 8, 0) = 0
close(4) = 0
fcntl(0, F_SETLKW, 0xFFBEDA28) = 0
accept(0, 0xFFBEDA50, 0xFFBED99C, 1) (sleeping...)
Bam. Goodbye. No error, no nothing.
Reproduce code:
---------------
<html>
<head>
</head>
<body>
<form method="post" action="response.php"
enctype="multipart/form-data">
<input name="test" type="file">
<input name="submit" value="submit" type="submit" />
</form>
</body>
</html>
Expected result:
----------------
The response.php should work - note, however, that php never even
attempts to open the response.php file, which is just a trivial "file
uploaded" message, no attempt to save.
Actual result:
--------------
See above truss - php just exits.
------------------------------------------------------------------------
--
Edit this bug report at [url]http://bugs.php.net/?id=38757&edit=1[/url]
dmitry@php.net Guest
-
davidb at pins dot net #5 #38757 [Fbk->Opn]: MultiPart Form Uploads fail with FastCGI
ID: 38757
User updated by: davidb at pins dot net
Reported By: davidb at pins dot net
-Status: Feedback
+Status: Open
Bug Type: Apache related
Operating System: Solaris 8
PHP Version: 5.1.6
Assigned To: dmitry
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2006-09-11 07:55:00] [email]dmitry@php.net[/email]
From the strace log I see: PHP FastCGI server accepts connection and
waits 1 sec (in pool()) for any input from HTTP client. It doesn't get
any data in a second and does save connection close.
Could you describe your environment: CPU speed, WebServer, fastcgi
plugin, fastcgi configuraion...
------------------------------------------------------------------------
[2006-09-09 21:09:16] [email]tony2001@php.net[/email]
Dmitry, could you plz check it out?
------------------------------------------------------------------------
[2006-09-09 02:05:01] davidb at pins dot net
Well, I tried with the latest 5.2b snapshot, and now it's broken for my
PC at home also. Appears to be the identical problem - php just
silently stops processing after it reads in the POST data, closes the
socket, and then waits for the next request, throwing a 500 server
error.
Please.
------------------------------------------------------------------------
[2006-09-08 22:09:08] [email]tony2001@php.net[/email]
Please try using this CVS snapshot:
[url]http://snaps.php.net/php5.2-latest.tar.gz[/url]
For Windows:
[url]http://snaps.php.net/win32/php5.2-win32-latest.zip[/url]
------------------------------------------------------------------------
[2006-09-08 22:04:15] davidb at pins dot net
Description:
------------
Greetings.
I'm currently observing a reproducible version of bug #26647 in the PHP
5.1 train. For a subset of users running mostly Mac but some PC
browsers, the PHP process unceremoniously exists witout comment when
the form is POST'ed. A truss of the PHP FastCGI process shows PHP
reading in the text (incidently, it's also pointed out a performance
issue where php's doing a read() of 8 bytes at a time from the FastCGI
stream instead of 8kB at at a time, but I digress). The problem
appears to go away when I switch to a non-FastCGI version.
The broken users are broken consistently - it would be possible (and
easy) to gdb trace it and see why it's exiting. Here's the start/end
of the truss:
accept(0, 0xFFBEDA50, 0xFFBED99C, 1) = 4
fcntl(0, F_SETLK, 0xFFBEDA28) = 0
poll(0xFFBED8F0, 1, 1000) = 0
shutdown(4, 1, 1) = 0
recv(4, "0101\001\0\b\0\0", 8, 0) = 8
recv(4, "\001\0\0\0\0\0\0", 8, 0) = 8
recv(4, "0104\001\015\0\0", 8, 0) = 8
recv(4, "0E05 C O N T E N", 8, 0) = 8
recv(4, " T _ L E N G T H", 8, 0) = 8
recv(4, " 8 3 5 1 90104\0", 8, 0) = 8
recv(4, "01\0 d\0\0\f V C", 8, 0) = 8
recv(4, " O N T E N T _ T", 8, 0) = 8
recv(4, " Y P E m u l t i", 8, 0) = 8
recv(4, " p a r t / f o r", 8, 0) = 8
recv(4, " m - d a t a ; ", 8, 0) = 8
recv(4, " b o u n d a r y", 8, 0) = 8
recv(4, " m L b O u N d A", 8, 0) = 8
(many many lines)
recv(4, " r Y - -\r\n0105", 8, 0) = 8
recv(4, "\001\0\0\0\0", 8, 0) = 6
recv(4, 0xFFBEDA28, 8, 0) = 0
close(4) = 0
fcntl(0, F_SETLKW, 0xFFBEDA28) = 0
accept(0, 0xFFBEDA50, 0xFFBED99C, 1) (sleeping...)
Bam. Goodbye. No error, no nothing.
Reproduce code:
---------------
<html>
<head>
</head>
<body>
<form method="post" action="response.php"
enctype="multipart/form-data">
<input name="test" type="file">
<input name="submit" value="submit" type="submit" />
</form>
</body>
</html>
Expected result:
----------------
The response.php should work - note, however, that php never even
attempts to open the response.php file, which is just a trivial "file
uploaded" message, no attempt to save.
Actual result:
--------------
See above truss - php just exits.
------------------------------------------------------------------------
--
Edit this bug report at [url]http://bugs.php.net/?id=38757&edit=1[/url]
davidb at pins dot net Guest
-
davidb at pins dot net #6 #38757 [Opn]: MultiPart Form Uploads fail with FastCGI
ID: 38757
User updated by: davidb at pins dot net
Reported By: davidb at pins dot net
Status: Open
Bug Type: Apache related
Operating System: Solaris 8
PHP Version: 5.1.6
Assigned To: dmitry
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2006-09-11 07:55:00] [email]dmitry@php.net[/email]
From the strace log I see: PHP FastCGI server accepts connection and
waits 1 sec (in pool()) for any input from HTTP client. It doesn't get
any data in a second and does save connection close.
Could you describe your environment: CPU speed, WebServer, fastcgi
plugin, fastcgi configuraion...
------------------------------------------------------------------------
[2006-09-09 21:09:16] [email]tony2001@php.net[/email]
Dmitry, could you plz check it out?
------------------------------------------------------------------------
[2006-09-09 02:05:01] davidb at pins dot net
Well, I tried with the latest 5.2b snapshot, and now it's broken for my
PC at home also. Appears to be the identical problem - php just
silently stops processing after it reads in the POST data, closes the
socket, and then waits for the next request, throwing a 500 server
error.
Please.
------------------------------------------------------------------------
[2006-09-08 22:09:08] [email]tony2001@php.net[/email]
Please try using this CVS snapshot:
[url]http://snaps.php.net/php5.2-latest.tar.gz[/url]
For Windows:
[url]http://snaps.php.net/win32/php5.2-win32-latest.zip[/url]
------------------------------------------------------------------------
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
[url]http://bugs.php.net/38757[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38757&edit=1[/url]
davidb at pins dot net Guest
-
dmitry@php.net #7 #38757 [Opn->Fbk]: MultiPart Form Uploads fail with FastCGI
ID: 38757
Updated by: [email]dmitry@php.net[/email]
Reported By: davidb at pins dot net
-Status: Open
+Status: Feedback
Bug Type: Apache related
Operating System: Solaris 8
PHP Version: 5.1.6
Assigned To: dmitry
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2006-09-11 07:55:00] [email]dmitry@php.net[/email]
From the strace log I see: PHP FastCGI server accepts connection and
waits 1 sec (in pool()) for any input from HTTP client. It doesn't get
any data in a second and does save connection close.
Could you describe your environment: CPU speed, WebServer, fastcgi
plugin, fastcgi configuraion...
------------------------------------------------------------------------
[2006-09-09 21:09:16] [email]tony2001@php.net[/email]
Dmitry, could you plz check it out?
------------------------------------------------------------------------
[2006-09-09 02:05:01] davidb at pins dot net
Well, I tried with the latest 5.2b snapshot, and now it's broken for my
PC at home also. Appears to be the identical problem - php just
silently stops processing after it reads in the POST data, closes the
socket, and then waits for the next request, throwing a 500 server
error.
Please.
------------------------------------------------------------------------
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
[url]http://bugs.php.net/38757[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38757&edit=1[/url]
dmitry@php.net Guest
-
davidb at pins dot net #8 #38757 [Asn]: MultiPart Form Uploads fail with FastCGI
ID: 38757
User updated by: davidb at pins dot net
Reported By: davidb at pins dot net
Status: Assigned
Bug Type: Apache related
Operating System: Solaris 8
PHP Version: 5.1.6
Assigned To: dmitry
New Comment:
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?
Previous Comments:
------------------------------------------------------------------------
[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]dmitry@php.net[/email]
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.
------------------------------------------------------------------------
[2006-09-11 07:55:00] [email]dmitry@php.net[/email]
From the strace log I see: PHP FastCGI server accepts connection and
waits 1 sec (in pool()) for any input from HTTP client. It doesn't get
any data in a second and does save connection close.
Could you describe your environment: CPU speed, WebServer, fastcgi
plugin, fastcgi configuraion...
------------------------------------------------------------------------
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
[url]http://bugs.php.net/38757[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38757&edit=1[/url]
davidb at pins dot net Guest
-
dmitry@php.net #9 #38757 [Asn->Fbk]: MultiPart Form Uploads fail with FastCGI
ID: 38757
Updated by: [email]dmitry@php.net[/email]
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]dmitry@php.net[/email]
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
[url]http://bugs.php.net/38757[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38757&edit=1[/url]
dmitry@php.net Guest
-
davidb at pins dot net #10 #38757 [Fbk->Opn]: MultiPart Form Uploads fail with FastCGI
ID: 38757
User updated by: davidb at pins dot net
Reported By: davidb at pins dot net
-Status: Feedback
+Status: Open
Bug Type: Apache related
Operating System: Solaris 8
PHP Version: 5.1.6
Assigned To: dmitry
New Comment:
Ummm...well, here's what I installed:
php5.2-200609141630
Does this have what I need? If not, can you tell me what URL to go
look for? I went to the snaps.php.net page for this.
Previous Comments:
------------------------------------------------------------------------
[2006-09-19 20:43:12] [email]dmitry@php.net[/email]
You have tested the old version, pool(..., 1000) means 1 second
timeout. In new version you should have 5 seconds.
------------------------------------------------------------------------
[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]dmitry@php.net[/email]
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.
------------------------------------------------------------------------
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
[url]http://bugs.php.net/38757[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38757&edit=1[/url]
davidb at pins dot net Guest
-
davidb at pins dot net #11 #38757 [Opn]: MultiPart Form Uploads fail with FastCGI
ID: 38757
User updated by: davidb at pins dot net
Reported By: davidb at pins dot net
Status: Open
Bug Type: Apache related
Operating System: Solaris 8
PHP Version: 5.1.6
Assigned To: dmitry
New Comment:
I just downloaded the latest snap php5.2-200609200230, but the poll()
still shows the same thing:
poll(0xFFBEDB18, 1, 1000) = 1
can you please tell me where to get the right stuff to test?
Thanks.
Previous Comments:
------------------------------------------------------------------------
[2006-09-19 20:52:55] davidb at pins dot net
Ummm...well, here's what I installed:
php5.2-200609141630
Does this have what I need? If not, can you tell me what URL to go
look for? I went to the snaps.php.net page for this.
------------------------------------------------------------------------
[2006-09-19 20:43:12] [email]dmitry@php.net[/email]
You have tested the old version, pool(..., 1000) means 1 second
timeout. In new version you should have 5 seconds.
------------------------------------------------------------------------
[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]dmitry@php.net[/email]
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.
------------------------------------------------------------------------
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
[url]http://bugs.php.net/38757[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38757&edit=1[/url]
davidb at pins dot net Guest
-
bjori@php.net #12 #38757 [Opn->Asn]: MultiPart Form Uploads fail with FastCGI
ID: 38757
Updated by: [email]bjori@php.net[/email]
Reported By: davidb at pins dot net
-Status: Open
+Status: Assigned
Bug Type: Apache related
Operating System: Solaris 8
PHP Version: 5.1.6
Assigned To: dmitry
Previous Comments:
------------------------------------------------------------------------
[2006-09-20 14:50:28] davidb at pins dot net
I just downloaded the latest snap php5.2-200609200230, but the poll()
still shows the same thing:
poll(0xFFBEDB18, 1, 1000) = 1
can you please tell me where to get the right stuff to test?
Thanks.
------------------------------------------------------------------------
[2006-09-19 20:52:55] davidb at pins dot net
Ummm...well, here's what I installed:
php5.2-200609141630
Does this have what I need? If not, can you tell me what URL to go
look for? I went to the snaps.php.net page for this.
------------------------------------------------------------------------
[2006-09-19 20:43:12] [email]dmitry@php.net[/email]
You have tested the old version, pool(..., 1000) means 1 second
timeout. In new version you should have 5 seconds.
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
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
[url]http://bugs.php.net/38757[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38757&edit=1[/url]
bjori@php.net Guest
-
davidb at pins dot net #13 #38757 [Asn]: MultiPart Form Uploads fail with FastCGI
ID: 38757
User updated by: davidb at pins dot net
Reported By: davidb at pins dot net
Status: Assigned
Bug Type: Apache related
Operating System: Solaris 8
PHP Version: 5.1.6
Assigned To: dmitry
New Comment:
Greetings.
I pulled the file out of CVS and built it. I see that the line you
changed is the struct tv{} stuff. After some testing, it looks like
moving it to 5 seconds helped, but did not fix the problem 100% of the
time.
I moved it to 20 seconds, and that seems to fix the problem for our
developers in Australia who were experiencing it the most. I also
backported this into 5.1.6 (it was only the single line change) and
that seems to work there as well.
Can we put this on closed for now, and I'll reopen it if it doesn't fix
it permenantly?
Previous Comments:
------------------------------------------------------------------------
[2006-09-20 14:50:28] davidb at pins dot net
I just downloaded the latest snap php5.2-200609200230, but the poll()
still shows the same thing:
poll(0xFFBEDB18, 1, 1000) = 1
can you please tell me where to get the right stuff to test?
Thanks.
------------------------------------------------------------------------
[2006-09-19 20:52:55] davidb at pins dot net
Ummm...well, here's what I installed:
php5.2-200609141630
Does this have what I need? If not, can you tell me what URL to go
look for? I went to the snaps.php.net page for this.
------------------------------------------------------------------------
[2006-09-19 20:43:12] [email]dmitry@php.net[/email]
You have tested the old version, pool(..., 1000) means 1 second
timeout. In new version you should have 5 seconds.
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
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
[url]http://bugs.php.net/38757[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38757&edit=1[/url]
davidb at pins dot net Guest
-
dmitry@php.net #14 #38757 [Asn->Csd]: MultiPart Form Uploads fail with FastCGI
ID: 38757
Updated by: [email]dmitry@php.net[/email]
Reported By: davidb at pins dot net
-Status: Assigned
+Status: Closed
Bug Type: Apache related
Operating System: Solaris 8
PHP Version: 5.1.6
Assigned To: dmitry
New Comment:
You can address this bug to mod_fastcgi people. It is really terrible
to allocate PHP process and make it wait for more then 5 seconds. I
don't like make PHP hang because of bugs (or bad decision) in it.
I am closing this bug.
You can try to use ZendEnabler from ZendCore distribution instead of
mod_fastcgi.
Previous Comments:
------------------------------------------------------------------------
[2006-09-26 14:05:24] davidb at pins dot net
Greetings.
I pulled the file out of CVS and built it. I see that the line you
changed is the struct tv{} stuff. After some testing, it looks like
moving it to 5 seconds helped, but did not fix the problem 100% of the
time.
I moved it to 20 seconds, and that seems to fix the problem for our
developers in Australia who were experiencing it the most. I also
backported this into 5.1.6 (it was only the single line change) and
that seems to work there as well.
Can we put this on closed for now, and I'll reopen it if it doesn't fix
it permenantly?
------------------------------------------------------------------------
[2006-09-20 14:50:28] davidb at pins dot net
I just downloaded the latest snap php5.2-200609200230, but the poll()
still shows the same thing:
poll(0xFFBEDB18, 1, 1000) = 1
can you please tell me where to get the right stuff to test?
Thanks.
------------------------------------------------------------------------
[2006-09-19 20:52:55] davidb at pins dot net
Ummm...well, here's what I installed:
php5.2-200609141630
Does this have what I need? If not, can you tell me what URL to go
look for? I went to the snaps.php.net page for this.
------------------------------------------------------------------------
[2006-09-19 20:43:12] [email]dmitry@php.net[/email]
You have tested the old version, pool(..., 1000) means 1 second
timeout. In new version you should have 5 seconds.
------------------------------------------------------------------------
[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?
------------------------------------------------------------------------
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
[url]http://bugs.php.net/38757[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38757&edit=1[/url]
dmitry@php.net Guest
-
davidb at pins dot net #15 #38757 [Csd]: MultiPart Form Uploads fail with FastCGI
ID: 38757
User updated by: davidb at pins dot net
Reported By: davidb at pins dot net
Status: Closed
Bug Type: Apache related
Operating System: Solaris 8
PHP Version: 5.1.6
Assigned To: dmitry
New Comment:
Greetings.
Does this mean you are *not* going to commit a fix of 20s, but will
leave in the 5s?
One can argue about where the error is, but if you consider a submit
from a remote site is uploading at 8kb/sec on average over 8 seconds,
than that's 8KB in 8 seconds. Even at 16kb/sec, you're going to take
more than 5 seconds to fill a 16KB or 32KB buffer, which is the buffer
between HTTP and mod_fastcgi.
Can this be a config option or something so I don't have to keep
patching? The downside of not putting in some sort of patch like this
is a slow connection upstream will get regular errors.
Previous Comments:
------------------------------------------------------------------------
[2006-10-03 09:24:01] [email]dmitry@php.net[/email]
You can address this bug to mod_fastcgi people. It is really terrible
to allocate PHP process and make it wait for more then 5 seconds. I
don't like make PHP hang because of bugs (or bad decision) in it.
I am closing this bug.
You can try to use ZendEnabler from ZendCore distribution instead of
mod_fastcgi.
------------------------------------------------------------------------
[2006-09-26 14:05:24] davidb at pins dot net
Greetings.
I pulled the file out of CVS and built it. I see that the line you
changed is the struct tv{} stuff. After some testing, it looks like
moving it to 5 seconds helped, but did not fix the problem 100% of the
time.
I moved it to 20 seconds, and that seems to fix the problem for our
developers in Australia who were experiencing it the most. I also
backported this into 5.1.6 (it was only the single line change) and
that seems to work there as well.
Can we put this on closed for now, and I'll reopen it if it doesn't fix
it permenantly?
------------------------------------------------------------------------
[2006-09-20 14:50:28] davidb at pins dot net
I just downloaded the latest snap php5.2-200609200230, but the poll()
still shows the same thing:
poll(0xFFBEDB18, 1, 1000) = 1
can you please tell me where to get the right stuff to test?
Thanks.
------------------------------------------------------------------------
[2006-09-19 20:52:55] davidb at pins dot net
Ummm...well, here's what I installed:
php5.2-200609141630
Does this have what I need? If not, can you tell me what URL to go
look for? I went to the snaps.php.net page for this.
------------------------------------------------------------------------
[2006-09-19 20:43:12] [email]dmitry@php.net[/email]
You have tested the old version, pool(..., 1000) means 1 second
timeout. In new version you should have 5 seconds.
------------------------------------------------------------------------
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
[url]http://bugs.php.net/38757[/url]
--
Edit this bug report at [url]http://bugs.php.net/?id=38757&edit=1[/url]
davidb at pins dot net Guest
Reply With QuoteSimilar Questions and Discussions
Posting Permissions
- You may not post new threads
- You may post replies
- You may not post attachments
- You may not edit your posts
