php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #41138 Broken output from PHP scrips (both in mod_php and fastcgi)
Submitted: 2007-04-19 07:57 UTC Modified: 2007-04-20 02:44 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: kovyrin at gmail dot com Assigned:
Status: Not a bug Package: Unknown/Other Function
PHP Version: 5.2.1 OS: Debian Linux 4.0 (2.6.17-2-686)
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: kovyrin at gmail dot com
New email:
PHP Version: OS:

 

 [2007-04-19 07:57 UTC] 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 <? phpinfo(); ?> 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 
<? phpinfo(); ?> 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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-04-19 08:04 UTC] tony2001@php.net
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 08:07 UTC] tony2001@php.net
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:15 UTC] kovyrin at gmail dot com
My fault - it does not work from local network :-(
 [2007-04-19 08:16 UTC] kovyrin at gmail dot com
Just tried it with latest snapshot - same results.
 [2007-04-19 08:23 UTC] 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:23 UTC] tony2001@php.net
How to reproduce it?
 [2007-04-19 08:27 UTC] 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:40 UTC] 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:45 UTC] tony2001@php.net
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 16:40 UTC] 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 17:52 UTC] 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 19:38 UTC] tony2001@php.net
>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 19:52 UTC] 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 20:04 UTC] tony2001@php.net
>Any advices about debugging/etc?
gdb & valgrind should help.
 [2007-04-19 21:55 UTC] kovyrin at gmail dot com
Hm, according to strace, php sends correct data to web servers (tried all of them with fastcgi). So, moving to web-server debugging...
 [2007-04-20 02:44 UTC] kovyrin at gmail dot com
Sorry guys, looks like it is some bug in linux kernel or in system libraries: http://blog.kovyrin.net/2007/04/20/sos/
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Sun Jul 27 10:00:02 2025 UTC