#41138 [Fbk->Opn]: Broken output from PHP scrips (both in mod_php and fastcgi)
ID: 41138 User updated by: kovyrin at gmail dot com Reported By: kovyrin at gmail dot com -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Debian Linux 4.0 (2.6.17-2-686) PHP Version: 5.2.1 New Comment: Hm, according to strace, php sends correct data to web servers (tried all of them with fastcgi). So, moving to web-server debugging... Previous Comments: [2007-04-19 20:04:31] [EMAIL PROTECTED] >Any advices about debugging/etc? gdb & valgrind should help. [2007-04-19 19:52:27] kovyrin at gmail dot com Just found out that with nginx these errors happen too (rarely, but they still there)... Guys, I'm desperate - I need your help. Any advices about debugging/etc? [2007-04-19 19:38:42] [EMAIL PROTECTED] >What proxies do you mean if requests from localhost produce "bad" >results? How should I know? >Really don't know how such things could happen We don't know either, since it works perfectly fine in all combinations. [2007-04-19 17:52:07] kovyrin at gmail dot com Guys, I have one major update: When I tried to setup the same configuration (php-fastcgi) using nginx web server (pointed to the same php socket) everything looks fine. Really don't know how such things could happen: apache+fcgi = bad, apache+mod_php = bad, lighttpd+fcgi = bad, nginx with the same fcgi processes = fine. [2007-04-19 16:40:40] kovyrin at gmail dot com What proxies do you mean if requests from localhost produce "bad" results? Considering we have two "bad" servers, it is really hard to say what's different. OS'es - different, deployment schemes - different (modphp and fastcgi), build options - we've tried many of them - no effect. What else should I check? 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/41138 -- Edit this bug report at http://bugs.php.net/?id=41138&edit=1
#41138 [Fbk->Opn]: Broken output from PHP scrips (both in mod_php and fastcgi)
ID: 41138 User updated by: kovyrin at gmail dot com Reported By: kovyrin at gmail dot com -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Debian Linux 4.0 (2.6.17-2-686) PHP Version: 5.2.1 New Comment: Just found out that with nginx these errors happen too (rarely, but they still there)... Guys, I'm desperate - I need your help. Any advices about debugging/etc? Previous Comments: [2007-04-19 19:38:42] [EMAIL PROTECTED] >What proxies do you mean if requests from localhost produce "bad" >results? How should I know? >Really don't know how such things could happen We don't know either, since it works perfectly fine in all combinations. [2007-04-19 17:52:07] kovyrin at gmail dot com Guys, I have one major update: When I tried to setup the same configuration (php-fastcgi) using nginx web server (pointed to the same php socket) everything looks fine. Really don't know how such things could happen: apache+fcgi = bad, apache+mod_php = bad, lighttpd+fcgi = bad, nginx with the same fcgi processes = fine. [2007-04-19 16:40:40] kovyrin at gmail dot com What proxies do you mean if requests from localhost produce "bad" results? Considering we have two "bad" servers, it is really hard to say what's different. OS'es - different, deployment schemes - different (modphp and fastcgi), build options - we've tried many of them - no effect. What else should I check? [2007-04-19 08:45:35] [EMAIL PROTECTED] Did you check the firewalls and proxies? What's the difference between the server where it works and the servers where it doesn't work? Configuration? Apache? Build options? Extensions? [2007-04-19 08:40:09] kovyrin at gmail dot com I've got one more server with the same problem. Tried 5.2.1 and latest snapshot - same results. Just if you're cutious: OS: CentOS 4.4 Datacenter: completely different Server: 2xXeon 3.2Ghz just as on the first mentioned server. 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/41138 -- Edit this bug report at http://bugs.php.net/?id=41138&edit=1
#41138 [Fbk->Opn]: Broken output from PHP scrips (both in mod_php and fastcgi)
ID: 41138 User updated by: kovyrin at gmail dot com Reported By: kovyrin at gmail dot com -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Debian Linux 4.0 (2.6.17-2-686) PHP Version: 5.2.1 New Comment: What proxies do you mean if requests from localhost produce "bad" results? Considering we have two "bad" servers, it is really hard to say what's different. OS'es - different, deployment schemes - different (modphp and fastcgi), build options - we've tried many of them - no effect. What else should I check? Previous Comments: [2007-04-19 08:45:35] [EMAIL PROTECTED] Did you check the firewalls and proxies? What's the difference between the server where it works and the servers where it doesn't work? Configuration? Apache? Build options? Extensions? [2007-04-19 08:40:09] kovyrin at gmail dot com I've got one more server with the same problem. Tried 5.2.1 and latest snapshot - same results. Just if you're cutious: OS: CentOS 4.4 Datacenter: completely different Server: 2xXeon 3.2Ghz just as on the first mentioned server. [2007-04-19 08:27:00] kovyrin at gmail dot com Guys, I don't know how to reproduce it on your servers. I have lots of php installations, but this is the first server with new PHP (all other servers use old 5.0 or even 4.X releases) and I've got described results. [2007-04-19 08:23:39] [EMAIL PROTECTED] How to reproduce it? [2007-04-19 08:23:34] kovyrin at gmail dot com Interesting example of this bug: www.trafficvalet.com/tv-access.log - 754204 bytes of access log file. www.trafficvalet.com/tv-access.log.php - the same file but with php extension. 1) wget www.trafficvalet.com/tv-access.log - 754204 bytes 2) wget www.trafficvalet.com/tv-access.log - 754204 bytes 3) wget www.trafficvalet.com/tv-access.log.php - 1665418 bytes 4) wget www.trafficvalet.com/tv-access.log.php - 1272050 bytes 5) wget www.trafficvalet.com/tv-access.log.php - 901900 bytes Try it yourself. 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/41138 -- Edit this bug report at http://bugs.php.net/?id=41138&edit=1
#41138 [Fbk->Opn]: Broken output from PHP scrips (both in mod_php and fastcgi)
ID: 41138 User updated by: kovyrin at gmail dot com Reported By: kovyrin at gmail dot com -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Debian Linux 4.0 (2.6.17-2-686) PHP Version: 5.2.1 New Comment: Guys, I don't know how to reproduce it on your servers. I have lots of php installations, but this is the first server with new PHP (all other servers use old 5.0 or even 4.X releases) and I've got described results. Previous Comments: [2007-04-19 08:23:39] [EMAIL PROTECTED] How to reproduce it? [2007-04-19 08:23:34] kovyrin at gmail dot com Interesting example of this bug: www.trafficvalet.com/tv-access.log - 754204 bytes of access log file. www.trafficvalet.com/tv-access.log.php - the same file but with php extension. 1) wget www.trafficvalet.com/tv-access.log - 754204 bytes 2) wget www.trafficvalet.com/tv-access.log - 754204 bytes 3) wget www.trafficvalet.com/tv-access.log.php - 1665418 bytes 4) wget www.trafficvalet.com/tv-access.log.php - 1272050 bytes 5) wget www.trafficvalet.com/tv-access.log.php - 901900 bytes Try it yourself. [2007-04-19 08:16:38] kovyrin at gmail dot com Just tried it with latest snapshot - same results. [2007-04-19 08:15:39] kovyrin at gmail dot com My fault - it does not work from local network :-( [2007-04-19 08:07:01] [EMAIL PROTECTED] Make sure there are no "smart" firewalls and proxies between that server and Internet. If you're saying it works from local net, but doesn't work from Internet, most likely it has nothing to do with PHP, since PHP does not care where the client is. 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/41138 -- Edit this bug report at http://bugs.php.net/?id=41138&edit=1
#41138 [Fbk->Opn]: Broken output from PHP scrips (both in mod_php and fastcgi)
ID: 41138 User updated by: kovyrin at gmail dot com Reported By: kovyrin at gmail dot com -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Debian Linux 4.0 (2.6.17-2-686) PHP Version: 5.2.1 New Comment: My fault - it does not work from local network :-( Previous Comments: [2007-04-19 08:07:01] [EMAIL PROTECTED] Make sure there are no "smart" firewalls and proxies between that server and Internet. If you're saying it works from local net, but doesn't work from Internet, most likely it has nothing to do with PHP, since PHP does not care where the client is. [2007-04-19 08:04:50] [EMAIL PROTECTED] 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 Cannot reproduce. [2007-04-19 07:57:53] kovyrin at gmail dot com Description: On one of our servers working with Debian GNU/Linux 4.0 we're experiencing really strange behavior of php. Even small php script which consists of produces defferent result on every execution. We've tried to use php as mod_php and as lighttpd+fastcgi, no luck - output contains binary data (one or many blocks of 0x00 bytes) sometimes these bytes are sent even before HTTP headers. We've tried php from debian repositories and 5.2.1 from official web site - results sometimes are different, but anyways they are not acceptable. One major thing about this error - script output should be big enough and download speed should be not so fast (it works from local network, but produces these weird results from any workstation in the Internet). Reproduce code: --- http://www.trafficvalet.com/phpinfo.php - this is simple script with inside. If you'll try to refresh page 5-10 times you'll get that broken result. If you'll not be able to get such results, http://www.trafficvalet.com/phpinfo.php.bin - this is one sample result. Expected result: phpinfo() output without \0 bytes. Actual result: -- One or more blocks of zero-bytes in output stream. -- Edit this bug report at http://bugs.php.net/?id=41138&edit=1
