#23580 [Fbk->Opn]: Random values for include_path

ID: 23580 Updated by: sniper@php.net Reported By: maximiliano dot marques at bol dot com dot br -Status: Feedback +Status: Open Bug Type: Apache related Operating System: Conectiva Linux 8 Kernel 2.4.19 PHP Version: 4.3.3RC5-dev New Comment: I got the files, thank you. Previous Comments: ------------------------------------------------------------------------ [2003-08-22 22:25:26] sniper@php.net 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. ------------------------------------------------------------------------ [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] sniper@php.net 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 ------------------------------------------------------------------------ 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