ID: 37641 User updated by: roguestar191 at comcast dot net Reported By: roguestar191 at comcast dot net Status: Open Bug Type: CGI related Operating System: linux PHP Version: 5.1.4 Assigned To: dmitry New Comment:
I've taken the time to create an ethereal dump of a first request - in case it's a problem with my server. it's possible I did something wrong but i don't see it. http://roguestar.dynu.com:5555/fcgidump (load with ethereal fcgidump). This is a dump of a request to php and back to a www.pastebin.com running on my server. Php is on port 4444, my server is port 46588 in this case. Previous Comments: ------------------------------------------------------------------------ [2006-05-31 11:41:51] roguestar191 at comcast dot net I use a purely custom webserver and custom fcgi module, both hand written by me. I detected the problem by launching: valgrind --tool=memcheck -v -v php-cgi -b 42000 Luanch my webserver Luanch a web browser Load a php page - Web browser never finish's loading I press control+c in valgrind, it always outputs it was on: fcgi_close_connection line 624/recv(). The only reason to "Read 8 bytes" at a time would be if padding were a multiple of 8 bytes, as suggest by: http://www.fastcgi.com/devkit/doc/fcgi-spec.html Quote: "We recommend that records be placed on boundaries that are multiples of eight bytes. The fixed-length portion of a FCGI_Record is eight bytes. " Changing strlen(buf) to 1 is not a potential fix, it is a fix, and it works, I've already tested it. At worst it will create 1-255 extra loops that do nothing except call recv() while recv still has things to return. (255 if the server pads with 255 bytes extra, which would be a total waste of bandwidth.) At best it will allow webservers that don't pad to a multiple of 8 bytes to work properly - and not freeze on recv() waiting for data that will never show up. The server isn't sending _anything_ special to the fcgi client app, it connects(), sends params, sends null on stdin(or post data), returns to the main select() function that returns ALL data from every single connection, waits for FCGI_END_REQUEST or for the socket to be closed, processing and buffering any FCGI_STDOUT data - sending stdout data at end_request. At end request it closes the socket - and prints to the client user whatever's left in the stdout buffer, runs a fast-cgi fifo (If two requests use the same fcgi program it fifo's them), or if FCGI_OVERLOADED or FCGI_CANT_MPX_CONN it will fifo the request. ------------------------------------------------------------------------ [2006-05-31 06:43:57] [EMAIL PROTECTED] I am not sure that the reason of problem is padding. Seems fcgi module doesn't close connection. Does it use FCGI_KEEP_CONN? What web server and fcgi module do you use? ------------------------------------------------------------------------ [2006-05-30 09:37:18] roguestar191 at comcast dot net sorry that should be "when the server doesn't pad all the packets to the size of 8" ------------------------------------------------------------------------ [2006-05-30 09:35:50] roguestar191 at comcast dot net Description: ------------ line 624 of sapi/cgi/fastcgi.c contains: while (recv(req->fd, buf, strlen(buf), 0) > 0) {} with buf being an array with 8 elements. With the server doesn't pad all packets to the size of 8 (Which is suggested but not required by the fast-cgi spec), this causes frequent lockups and failed requests. (Without that padding, I have no idea about with it). My fix was simple - change strlen(buf) (which returns 8), to 1, so it will read any excess bytes at the end and cleanly close and continue on, even if it's not a multiple of 8 bytes. Thank you for php! Expected result: ---------------- fast-cgi padding to be read and thrown out, requests to close. Actual result: -------------- request tends to lock up on recv when packets arn't a multiple of 8 in size. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=37641&edit=1