ID: 23580 Updated by: [EMAIL PROTECTED] Reported By: maximiliano dot marques at bol dot com dot br -Status: Open +Status: Feedback Bug Type: Apache related Operating System: Conectiva Linux 8 Kernel 2.4.19 -PHP Version: 4.3.2 +PHP Version: 4.3.3RC5-dev New Comment:
Please start by reducing your configs (php.ini / httpd.conf / etc) to bare minimum with which you still can reproduce this reliably. (I would guess this should be possible to reproduce with only 2 virtualhosts) php.ini: Remove all settings which you have not touched Then send me those files. Previous Comments: ------------------------------------------------------------------------ [2003-08-22 22:05:10] maximiliano dot marques at bol dot com dot br Yes I have just tried the latest snap from snaps.php.net and this problem still exists! ------------------------------------------------------------------------ [2003-08-15 08:33:28] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip And adjust the version accordingly if problem persists. ------------------------------------------------------------------------ [2003-08-07 01:38:57] 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: <?php 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/ web"); 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-08-07 01:13:14] 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 http://nbtsc.org/~noam/info.php 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: <?php 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/info.nbtsc.org/photos/" (which is a fragment of the path '/home/sites/info.nbtsc.org/photos'). 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? Noam ------------------------------------------------------------------------ [2003-07-23 10:33:02] [EMAIL PROTECTED] 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... ------------------------------------------------------------------------ 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/23580 -- Edit this bug report at http://bugs.php.net/?id=23580&edit=1
