|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #23580 Random values for include_path
Submitted: 2003-05-10 22:31 UTC Modified: 2004-01-28 14:23 UTC
Avg. Score:4.9 ± 0.3
Reproduced:13 of 13 (100.0%)
Same Version:9 (69.2%)
Same OS:3 (23.1%)
From: maximiliano dot marques at bol dot com dot br Assigned:
Status: Not a bug Package: Apache related
PHP Version: 4.3.3 OS: *
Private report: No CVE-ID: None
 [2003-05-10 22:31 UTC] maximiliano dot marques at bol dot com dot br
This is the same bug #7174 except it happens on Apache/1.3.26 (Unix) (Conectiva/Linux) PHP/4.3.1 mod_ssl/2.8.10 OpenSSL/0.9.6c 

I get different values on phpinfo(); -page for include_path everytime I make a new request - it seems that all values present in my site are shown randomly after I have made requests to pages using different include_path -settings.

'./configure' '--prefix=/usr' '--with-config-file-path=/etc' '--disable-debug' '--enable-inline-optimization' '--with-apxs' '--with-exec-dir=/usr/bin' '--with-regex=system' '--with-gettext' '--with-gd' '--with-jpeg-dir=/usr' '--with-png' '--enable-sysvsem' '--enable-sysvshm' '--enable-yp' '--enable-ftp' '--enable-wddx' '--with-mysql' '--with-xml' '--with-mhash' '--with-mcrypt=/usr/local/src/libmcrypt-2.5.3' '--with-mm' '--with-xpm-dir' '--with-imap' '--with-imap-ssl' '--enable-openssl' '--with-gdbm' '--with-zlib' '--with-zip' 

PHP API: 20020918 
PHP Extension: 20020429 
Zend Extension: 20021010 
Apache Release: 10326100 
Apache API: 19990320 


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-06-19 02:25 UTC] maximiliano dot marques at bol dot com dot br
Yes I did and it behave exactly the same.

And I also compiled without

and nothing changed.

I have set include_path in httpd.conf. The follow code I extracted from my httpd.conf. I am working only with virtual hosts.

<VirtualHost *:80>
    DocumentRoot /sites/imax/http
    ServerAlias imax
    ErrorLog logs/imax-error_log
    CustomLog logs/imax-access_log common
    php_value include_path .:/sites/imax/includes:/sites/imax/instance/imx/includes
    Alias /photo/ "/sites/imax/instance/imx/photo/"
    Alias /file/ "/sites/imax/instance/imx/file/"
    Alias /img/ "/sites/imax/instance/imx/img/"
    Alias /img_dyn/ "/sites/imax/instance/imx/img_dyn/"
    Alias /style/ "/sites/imax/instance/imx/style/"
    Alias /https/ "/sites/imax/https/"
 [2003-06-23 20:13 UTC]
Try adding "'s around the path. (I always have them around the paths, e.g. 'php_value include_path "/www/common/:."')

Some questions we need get answers for:
Do you set the include_path for _every_ vhost?
Do you have php.ini and is it loaded?
What is the include_path setting in your php.ini?
How many vhosts do you have in your httpd.conf?
If you start apache in single server mode, does it still
happen for every request? (httpd -X -F -DSSL)

Please run all these tests using this script:

<?php echo ini_get('include_path'); ?>

 [2003-06-25 07:34 UTC] maximiliano dot marques at bol dot com dot br
First answering your questions:

>Do you set the include_path for _every_ vhost?
Not every but almost. I have 7 vhosts and 5 using different include_path values.
>Do you have php.ini and is it loaded?
Yes, I do and it was loaded since it appear in phpinfo() briefing.
>What is the include_path setting in your php.ini?
include_path = "."
>How many vhosts do you have in your httpd.conf?
7 and I use dynamic IP for all. 3 of them are using same DocumentRoot but different include_path values.
>If you start apache in single server mode, does it still
happen for every request? (httpd -X -F -DSSL)
Yes, it does. However as in this case there is only one process running, at first request it keep the include_path value forever. I am explaining better below.
Second I executed several tests including your recommendations above, adding _?_ around the path and I used netstat and ps to follow httpd child process behavior while I running your suggested script:
<?php echo ini_get('include_path'); ?>

My conclusion was that the first request that a child process run with include_path given, it cache the value for include_path (no matter if it was set in httpd.conf or .htaccess, I tried with both) and child process never change include_path value anymore while it still alive.

I am using ?MaxRequestsPerChild 1? as workaround and however it is working, performance is debilitated.
 [2003-07-23 10:33 UTC]
I'm trying to reproduce this, but so far without any success.  I tried to stress-test PHP with multiple vhosts and see if there are any 'leaks' of include_paths - but after hundreds of thousands of requests, there were none.

I'm very interested in what you say about the single-process mode.  Basically, what you describe is *not* the behavior PHP is supposed to display.  The include_path settings should go back to its original setting at the end of each request.  This is also the behavior that I'm seeing in my setup.

How did you determine that the include_path setting remains 'cached'?

If that is really the case, then it would greatly help if you could provide me with temporary access to your server, so I can debug this.

If it's not the case, then it appears we're back in square one...
 [2003-08-07 01:13 UTC] ns at canada dot com
We've been having this problem as well. In support of the caching hypothesis, here's some info I've collected.

This is PHP 4.3.2; phpinfo() is available at

The include_path for our server is set in php.ini to ".:/usr/share/pear". phpinfo() verifies this as the master setting.

Output from 'ps xaf' showing the httpd processes:

30908 ?        SN     0:02 httpd
30930 ?        SN     0:00  \_ httpd
30932 ?        SN     0:00  |   \_ httpd
30936 ?        SN     1:52  |       \_ httpd
30962 ?        SN     2:00  |       \_ httpd
... (30963 through 30985)
30986 ?        SN     0:01  |       \_ httpd
19881 ?        SN     0:00  \_ httpd
19882 ?        SN     0:00  |   \_ httpd
19884 ?        SN     1:41  |       \_ httpd
... (19885 through 19908)
19909 ?        SN     0:01  |       \_ httpd
11727 ?        SN     0:00  \_ httpd
11728 ?        SN     0:00      \_ httpd
11730 ?        SN     0:15          \_ httpd
... (11731 through 11754)
11755 ?        SN     0:00          \_ httpd

I then ran 'w3m -dump' in a loop, loading this simple php script 100 times:

print "getmypid() = " . getmypid() . "  ";
print "ini_get(include_path) = " . ini_get("include_path") . "<br />\n";

I find the output rather interesting. All the requests served by PIDs in the 30xxx range (one branch of the httpd process tree) are have consistently incorrect include_path="tes/" (which is a fragment of the path '/home/sites/'). All the requests served by PIDs in the 19xxx range have consistently correct include_path=".:/usr/share/pear". The requests served by PIDs in the 11xxx range have varying include_paths; sometimes, when the same process served a second request, it had a different include path from the first time. The include_paths from the 11xxx range are either ".:/usr/share/pear", "2.php", or (in hexadecimal) 0x58 0xCC 0x20 0x20. What I haven't been able to figure out is where these include_paths are coming from.

I will see what more I can track down, and zeev, I can check with the main server administrator to see about getting you temporary access. What level of access would you need?

 [2003-08-07 01:38 UTC] ns at canada dot com
Looks like the caching isn't happening quite like I 
thought it was. Running this script a couple of times 
in the same httpd process:

        print "getmypid() = " . getmypid() . "  ";
        print "ini_get(include_path) = " . 
ini_get("include_path") . "<br />\n";
        print "Setting include_path...<br />\n";
        ini_set("include_path", "/home/users/noam/
        print "getmypid() = " . getmypid() . "  ";
        print "ini_get(include_path) = " . 
ini_get("include_path") . "<br />\n";

shows that the include_path is always as configured in 
php.ini at the beginning of the script. (i.e. the 
ini_set doesn't persist.)

Using Apache 2.0.47.
 [2003-10-04 00:50 UTC]
See bug #25753 (placeholder for all these reports about leaking php ini settings)
 [2004-01-28 14:23 UTC]
This should now be fixed in CVS. Fix scheduled for PHP 4.3.5.
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Sun Mar 26 09:05:48 2023 UTC