|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #26810 During high load, PHP dumps sourcecode
Submitted: 2004-01-06 05:08 UTC Modified: 2004-03-25 11:27 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: Assigned:
Status: Not a bug Package: Scripting Engine problem
PHP Version: 4.3.4 OS: Linux Redhat 7.3
Private report: No CVE-ID: None
 [2004-01-06 05:08 UTC]
During high load on our hosting servers, some customers are complaining that their PHP sourcecode gets dumped to the browser (we have several screenshots of this)

Each VirtualHost has a bandwidth limit which could be the reason for this, however the problem has not occured on any of our other 15 servers which uses versions lower than 4.3.4, it has only happened on the two servers that use 4.3.4, which seems to justify a pattern

A phpinfo for the two servers can be found here:

Reproduce code:
Hard to reproduce

Expected result:
The output from the parsed PHP file

Actual result:
The sourcecode of each PHP file


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2004-01-06 17:41 UTC]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.

Would be nice to know what webserver is used for starters.
Also, see bug #25753 which I believe is the same bug as this is.

 [2004-01-06 17:43 UTC]
Ignore the webserver thing, I'm slow today. (didn't notice those phpinfo() urls.. :I)

Do you use any php_value or similar settings in httpd.conf?
(or any .htaccess file) Do you happen to set 'engine' php.ini setting in those if you have any?

 [2004-01-07 06:41 UTC]
There are no php_* vars in the problematic-virtualhosts.

But there are some php_* values in the other virtualhosts (like `php_admin_flag engine off`), so it could be related to bug #25753. 
I can't be sure, for now I will mark this bug a dup and wait for bug #25753 to be fixed, which I hope will be _very_ soon :)
 [2004-01-07 21:01 UTC]
don't use duplicate status..

 [2004-01-11 15:41 UTC] community-team at gmx dot net
I have upgraded my server to php-4.3.4 with apache 2.0.48 and after the server was used for a few minutes, people got a download box and could download the php source code.

On I read about a possible caching problem in apache 2.0.48. I did not understand everything there, so I just decided to downgrade to Apache 1.3.29 which ran very stable. 
But after a while, the PHP source was dumped to the browser, too. I set the server onto heavy load for 15 minutes directly after i restarted apache and there was no problem. But about 30 minutes later, I could read source code again, although the server's load was about 0.

Now I downgraded to PHP 4.3.2 but I _still_ get the source dumped to the browser.

On a Macintosh running PHP 4.3.2 (not the original Apple build, but the build from ) and Apache 1.3.29 those problems do not exist.

I think I will try the configure command tomsommer used. And I will do this with PHP 4.3.3, too.

Btw, my configure command was:

./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=i386-redhat-linux --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --cache-file=../config.cache --with-config-file-path=/etc --with-config-file-scan-dir=/etc/php.d --enable-force-cgi-redirect --disable-debug --enable-pic --disable-rpath --enable-inline-optimization --with-bz2 --with-db4=/usr --with-exec-dir=/usr/bin --with-freetype-dir=/usr --with-png-dir=/usr --with-gd --enable-gd-native-ttf --with-gdbm --with-gettext --with-ncurses --with-gmp --with-iconv --with-jpeg-dir=/usr --with-openssl --with-png --with-regex=system --with-expat-dir=/usr --with-dom=shared,/usr --with-dom-xslt=/usr --with-dom-exslt=/usr --with-pcre=/usr --with-zlib --with-layout=GNU --enable-bcmath --enable-exif --enable-ftp --enable-magic-quotes --enable-safe-mode --enable-sockets --enable-sysvsem --enable-sysvshm --enable-discard-path --enable-track-vars --enable-trans-sid --enable-yp --enable-wddx --without-oci8 --with-pear=/usr/share/pear --with-imap --with-imap-ssl --with-kerberos --with-ldap --with-mysql --with-snmp=shared,/usr --with-snmp=shared --enable-ucd-snmp-hack --enable-memory-limit --enable-bcmath --enable-shmop --enable-calendar --enable-dbx --enable-dio --enable-mcal --enable-mbstring --enable-mbstr-enc-trans --enable-mbregex --with-apxs=/etc/httpd/bin/apxs
 [2004-01-12 13:28 UTC] community-team at gmx dot net
Ok I installed PHP 4.3.3 now, but the problem still persists.

But I wondered, why the error only occurs on and on

A deeper look into the source, especially into the include paths showed up, that those are the only 2 files in which I include php files from a parent directory ("../file.php").

So I assume that the bug that PHP source is dumped to the browser may somehow be connected with the open_basedir bug.
 [2004-03-25 03:36 UTC] phpbug26810 at pech dot cz
Hi, I have the same problem with PHP 4.3.4 from Fedora Core 1 on Apache 2.0.48 on FC1 linux. This is really hard to reproduce and I don't think it's really connected with server load. I think it's somethink like bug #25753, but it must be somewhere else in the code because I have patched PHP to avoid 25753 buggy behavior.

When I refresh the page, it sometimes returns predicted output, but sometimes it returns source PHP code to the browser.

It works same way with output buffering on or off. Do you need more info?
 [2004-03-25 11:27 UTC]
Try a newer version of PHP. 
This is fixed in 4.3.5RC3 - I don't have the problem anymore
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Fri Sep 17 06:03:36 2021 UTC