Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

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.

Dmitry, could you plz check it out?

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...

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.

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 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.

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.

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?

You have tested the old version, pool(..., 1000) means 1 second timeout. In new version you should have 5 seconds.

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.

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.

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?

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.

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.