#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: manuel at mausz dot at Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: ping Previous Comments: [2008-03-07 20:21:13] oliver dot graetz at gmx dot de In order to avoid getting my report marked as a duplicate of this one: I have experienced a similar problem with PHP 5.2.5. I am using set_include_path() but the PHP ignores the call and uses the value defined in the main php.ini file. [2008-02-26 12:22:18] manuel at mausz dot at Yes. The bug only occurs if you're mixing php_admin_value and php_value with the same ini-setting. [2008-02-26 11:18:06] admin at scuolacomunicazioneiulm dot it I've exactly the same system of [ryan at djurovich dot com] Plesk 8.3.0 CentOS 4 linux 2.6.9-023stab033.9-enterprise apache 2.0.52-32.3 php 5.2.5-4 updated this night :( (oh, don't I could sleep, don't?!) I think this bug is going to become so much serious as Plesk users update their systems! Error could be seen in www.fondazioneiulm.it and www.scuolacomunicazioneiulm.it. These sites are both built on Zend Framework, like [it at inmolinkmls dot com] application. Some request load Zend/Loader.php, some not (but I have display_errors = off, so you'll see a blank page instead of error). Do you think that the hack to change php_admin_value to php_value in Plesk confs could patch this kind of situation? MP [2008-02-25 05:39:06] ryan at djurovich dot com Confirmed, running server with Plesk 8.3.0: CentOS 4 linux 2.6.9-023stab033.9-enterprise apache 2.0.52-32.3 php 5.2.5-4 [2008-02-21 18:40:36] root at net1 dot cc I can confirm both of Manuel's patches fix the problem on another machine, too. Also, the first patch is used in production since it was made, and I have not encountered any problems up to now. It's high time devs look at this issue, isn't it? 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: oliver dot graetz at gmx dot de Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: In order to avoid getting my report marked as a duplicate of this one: I have experienced a similar problem with PHP 5.2.5. I am using set_include_path() but the PHP ignores the call and uses the value defined in the main php.ini file. Previous Comments: [2008-02-26 12:22:18] manuel at mausz dot at Yes. The bug only occurs if you're mixing php_admin_value and php_value with the same ini-setting. [2008-02-26 11:18:06] admin at scuolacomunicazioneiulm dot it I've exactly the same system of [ryan at djurovich dot com] Plesk 8.3.0 CentOS 4 linux 2.6.9-023stab033.9-enterprise apache 2.0.52-32.3 php 5.2.5-4 updated this night :( (oh, don't I could sleep, don't?!) I think this bug is going to become so much serious as Plesk users update their systems! Error could be seen in www.fondazioneiulm.it and www.scuolacomunicazioneiulm.it. These sites are both built on Zend Framework, like [it at inmolinkmls dot com] application. Some request load Zend/Loader.php, some not (but I have display_errors = off, so you'll see a blank page instead of error). Do you think that the hack to change php_admin_value to php_value in Plesk confs could patch this kind of situation? MP [2008-02-25 05:39:06] ryan at djurovich dot com Confirmed, running server with Plesk 8.3.0: CentOS 4 linux 2.6.9-023stab033.9-enterprise apache 2.0.52-32.3 php 5.2.5-4 [2008-02-21 18:40:36] root at net1 dot cc I can confirm both of Manuel's patches fix the problem on another machine, too. Also, the first patch is used in production since it was made, and I have not encountered any problems up to now. It's high time devs look at this issue, isn't it? [2008-02-21 12:56:43] tallyce at gmail dot com See also bug http://bugs.php.net/bug.php?id=44178 which I now see describes the same behaviour. 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: admin at scuolacomunicazioneiulm dot it Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: I've exactly the same system of [ryan at djurovich dot com] Plesk 8.3.0 CentOS 4 linux 2.6.9-023stab033.9-enterprise apache 2.0.52-32.3 php 5.2.5-4 updated this night :( (oh, don't I could sleep, don't?!) I think this bug is going to become so much serious as Plesk users update their systems! Error could be seen in www.fondazioneiulm.it and www.scuolacomunicazioneiulm.it. These sites are both built on Zend Framework, like [it at inmolinkmls dot com] application. Some request load Zend/Loader.php, some not (but I have display_errors = off, so you'll see a blank page instead of error). Do you think that the hack to change php_admin_value to php_value in Plesk confs could patch this kind of situation? MP Previous Comments: [2008-02-25 05:39:06] ryan at djurovich dot com Confirmed, running server with Plesk 8.3.0: CentOS 4 linux 2.6.9-023stab033.9-enterprise apache 2.0.52-32.3 php 5.2.5-4 [2008-02-21 18:40:36] root at net1 dot cc I can confirm both of Manuel's patches fix the problem on another machine, too. Also, the first patch is used in production since it was made, and I have not encountered any problems up to now. It's high time devs look at this issue, isn't it? [2008-02-21 12:56:43] tallyce at gmail dot com See also bug http://bugs.php.net/bug.php?id=44178 which I now see describes the same behaviour. [2008-02-18 16:59:59] laurent_dorer at yahoo dot fr One more thing, does someone knows if installing suExec for Apache and then use multiple php.ini, would correct this very annoying problem [2008-02-18 14:18:54] laurent_dorer at yahoo dot fr I forgot to describe the server in my last submission , so : PHP: 5.2.0-8+etch10 (apache2handler) MySQL: 5.0.32-Debian_7etch5-log and apache 2.2.3-4 pardon my english !! 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: manuel at mausz dot at Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: Yes. The bug only occurs if you're mixing php_admin_value and php_value with the same ini-setting. Previous Comments: [2008-02-26 11:18:06] admin at scuolacomunicazioneiulm dot it I've exactly the same system of [ryan at djurovich dot com] Plesk 8.3.0 CentOS 4 linux 2.6.9-023stab033.9-enterprise apache 2.0.52-32.3 php 5.2.5-4 updated this night :( (oh, don't I could sleep, don't?!) I think this bug is going to become so much serious as Plesk users update their systems! Error could be seen in www.fondazioneiulm.it and www.scuolacomunicazioneiulm.it. These sites are both built on Zend Framework, like [it at inmolinkmls dot com] application. Some request load Zend/Loader.php, some not (but I have display_errors = off, so you'll see a blank page instead of error). Do you think that the hack to change php_admin_value to php_value in Plesk confs could patch this kind of situation? MP [2008-02-25 05:39:06] ryan at djurovich dot com Confirmed, running server with Plesk 8.3.0: CentOS 4 linux 2.6.9-023stab033.9-enterprise apache 2.0.52-32.3 php 5.2.5-4 [2008-02-21 18:40:36] root at net1 dot cc I can confirm both of Manuel's patches fix the problem on another machine, too. Also, the first patch is used in production since it was made, and I have not encountered any problems up to now. It's high time devs look at this issue, isn't it? [2008-02-21 12:56:43] tallyce at gmail dot com See also bug http://bugs.php.net/bug.php?id=44178 which I now see describes the same behaviour. [2008-02-18 16:59:59] laurent_dorer at yahoo dot fr One more thing, does someone knows if installing suExec for Apache and then use multiple php.ini, would correct this very annoying problem 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: ryan at djurovich dot com Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: Confirmed, running server with Plesk 8.3.0: CentOS 4 linux 2.6.9-023stab033.9-enterprise apache 2.0.52-32.3 php 5.2.5-4 Previous Comments: [2008-02-21 18:40:36] root at net1 dot cc I can confirm both of Manuel's patches fix the problem on another machine, too. Also, the first patch is used in production since it was made, and I have not encountered any problems up to now. It's high time devs look at this issue, isn't it? [2008-02-21 12:56:43] tallyce at gmail dot com See also bug http://bugs.php.net/bug.php?id=44178 which I now see describes the same behaviour. [2008-02-18 16:59:59] laurent_dorer at yahoo dot fr One more thing, does someone knows if installing suExec for Apache and then use multiple php.ini, would correct this very annoying problem [2008-02-18 14:18:54] laurent_dorer at yahoo dot fr I forgot to describe the server in my last submission , so : PHP: 5.2.0-8+etch10 (apache2handler) MySQL: 5.0.32-Debian_7etch5-log and apache 2.2.3-4 pardon my english !! [2008-02-18 14:07:18] laurent_dorer at yahoo dot fr Hi, we have got the same problem here: two virtualhost for our site in utf8 (with mbstring activated) and another virtualhost for our mediawiki. The problem occurs when someone goes on the web site (mbstring.func_overload 6) then, the mediawiki (mbstring.func_overload 0) starts to behave randomly = sometimes it's ok and sometime it's like if func_overload was set to 6. I spend a lot of time to found this was a bug, and didn't find any solution... neither in apache bugs, nor php bug :( 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: tallyce at gmail dot com Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: See also bug http://bugs.php.net/bug.php?id=44178 which I now see describes the same behaviour. Previous Comments: [2008-02-18 16:59:59] laurent_dorer at yahoo dot fr One more thing, does someone knows if installing suExec for Apache and then use multiple php.ini, would correct this very annoying problem [2008-02-18 14:18:54] laurent_dorer at yahoo dot fr I forgot to describe the server in my last submission , so : PHP: 5.2.0-8+etch10 (apache2handler) MySQL: 5.0.32-Debian_7etch5-log and apache 2.2.3-4 pardon my english !! [2008-02-18 14:07:18] laurent_dorer at yahoo dot fr Hi, we have got the same problem here: two virtualhost for our site in utf8 (with mbstring activated) and another virtualhost for our mediawiki. The problem occurs when someone goes on the web site (mbstring.func_overload 6) then, the mediawiki (mbstring.func_overload 0) starts to behave randomly = sometimes it's ok and sometime it's like if func_overload was set to 6. I spend a lot of time to found this was a bug, and didn't find any solution... neither in apache bugs, nor php bug :( [2008-02-14 12:06:42] it at inmolinkmls dot com We have compiled the latest CVS snapshot (http://snaps.php.net/php5.2-latest.tar.gz) on Linux kernel 2.6.9-42.plus.c4 (Centos 4) as apache2 module with no luck. We have used just the most basic configuration (--with-apxs2=/wwwroot/bin/apxs). We have been able to reproduce the bug with 2 virtualhost, one with php_value and another one with php_admin_value. As soon as we load the one with php_admin_value, the include_path of the first one starts to randomly fail. We have a serious problem with this bug, since we are developing an application with Zend Framework (Did you realize how seriously this bug affects Zend Framework MVC (Zend/Loader.php / loadFile (#125))? It just doesn't work at all because of the bug). Hope to see this bug solved soon. [2008-02-07 00:56:08] manuel at mausz dot at There's no need to test this. I can still see the bug in CVS. Look at zend_ini.c: ini_entry-modifiable gets modified (... = ZEND_INI_SYSTEM) and won't get restored after the request has been processed (zend_restore_ini_entry_cb). 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: laurent_dorer at yahoo dot fr Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: Hi, we have got the same problem here: two virtualhost for our site in utf8 (with mbstring activated) and another virtualhost for our mediawiki. The problem occurs when someone goes on the web site (mbstring.func_overload 6) then, the mediawiki (mbstring.func_overload 0) starts to behave randomly = sometimes it's ok and sometime it's like if func_overload was set to 6. I spend a lot of time to found this was a bug, and didn't find any solution... neither in apache bugs, nor php bug :( Previous Comments: [2008-02-14 12:06:42] it at inmolinkmls dot com We have compiled the latest CVS snapshot (http://snaps.php.net/php5.2-latest.tar.gz) on Linux kernel 2.6.9-42.plus.c4 (Centos 4) as apache2 module with no luck. We have used just the most basic configuration (--with-apxs2=/wwwroot/bin/apxs). We have been able to reproduce the bug with 2 virtualhost, one with php_value and another one with php_admin_value. As soon as we load the one with php_admin_value, the include_path of the first one starts to randomly fail. We have a serious problem with this bug, since we are developing an application with Zend Framework (Did you realize how seriously this bug affects Zend Framework MVC (Zend/Loader.php / loadFile (#125))? It just doesn't work at all because of the bug). Hope to see this bug solved soon. [2008-02-07 00:56:08] manuel at mausz dot at There's no need to test this. I can still see the bug in CVS. Look at zend_ini.c: ini_entry-modifiable gets modified (... = ZEND_INI_SYSTEM) and won't get restored after the request has been processed (zend_restore_ini_entry_cb). [2008-02-07 00:47:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi Just to be sure this isn't fixed already. There were some changes done but I'm not sure anymore if those actually went into 5.2.5 and I don't have Apache setup around to test right now.. [2008-02-07 00:45:48] [EMAIL PROTECTED] See also bug #43755 [2008-01-21 18:37:21] manuel at mausz dot at As I said before, my patch breaks the ini settings abi resulting in segfaults if old extensions are loaded. Due to the fact that one of my customers is using a proprietary extension I have implemented an alternate, dirty but hopefully non-breaking patch. The patch stores the original value 3 bits to the left of the new value. This method won't break any php or pecl extensions (all checked). Only ext/reflection needs to be recompiled. http://manuel.mausz.at/coding/patches/php/5.2.5/php5.2.5-restore-ini-level2.patch 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: laurent_dorer at yahoo dot fr Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: I forgot to describe the server in my last submission , so : PHP: 5.2.0-8+etch10 (apache2handler) MySQL: 5.0.32-Debian_7etch5-log and apache 2.2.3-4 pardon my english !! Previous Comments: [2008-02-18 14:07:18] laurent_dorer at yahoo dot fr Hi, we have got the same problem here: two virtualhost for our site in utf8 (with mbstring activated) and another virtualhost for our mediawiki. The problem occurs when someone goes on the web site (mbstring.func_overload 6) then, the mediawiki (mbstring.func_overload 0) starts to behave randomly = sometimes it's ok and sometime it's like if func_overload was set to 6. I spend a lot of time to found this was a bug, and didn't find any solution... neither in apache bugs, nor php bug :( [2008-02-14 12:06:42] it at inmolinkmls dot com We have compiled the latest CVS snapshot (http://snaps.php.net/php5.2-latest.tar.gz) on Linux kernel 2.6.9-42.plus.c4 (Centos 4) as apache2 module with no luck. We have used just the most basic configuration (--with-apxs2=/wwwroot/bin/apxs). We have been able to reproduce the bug with 2 virtualhost, one with php_value and another one with php_admin_value. As soon as we load the one with php_admin_value, the include_path of the first one starts to randomly fail. We have a serious problem with this bug, since we are developing an application with Zend Framework (Did you realize how seriously this bug affects Zend Framework MVC (Zend/Loader.php / loadFile (#125))? It just doesn't work at all because of the bug). Hope to see this bug solved soon. [2008-02-07 00:56:08] manuel at mausz dot at There's no need to test this. I can still see the bug in CVS. Look at zend_ini.c: ini_entry-modifiable gets modified (... = ZEND_INI_SYSTEM) and won't get restored after the request has been processed (zend_restore_ini_entry_cb). [2008-02-07 00:47:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi Just to be sure this isn't fixed already. There were some changes done but I'm not sure anymore if those actually went into 5.2.5 and I don't have Apache setup around to test right now.. [2008-02-07 00:45:48] [EMAIL PROTECTED] See also bug #43755 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: laurent_dorer at yahoo dot fr Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: One more thing, does someone knows if installing suExec for Apache and then use multiple php.ini, would correct this very annoying problem Previous Comments: [2008-02-18 14:18:54] laurent_dorer at yahoo dot fr I forgot to describe the server in my last submission , so : PHP: 5.2.0-8+etch10 (apache2handler) MySQL: 5.0.32-Debian_7etch5-log and apache 2.2.3-4 pardon my english !! [2008-02-18 14:07:18] laurent_dorer at yahoo dot fr Hi, we have got the same problem here: two virtualhost for our site in utf8 (with mbstring activated) and another virtualhost for our mediawiki. The problem occurs when someone goes on the web site (mbstring.func_overload 6) then, the mediawiki (mbstring.func_overload 0) starts to behave randomly = sometimes it's ok and sometime it's like if func_overload was set to 6. I spend a lot of time to found this was a bug, and didn't find any solution... neither in apache bugs, nor php bug :( [2008-02-14 12:06:42] it at inmolinkmls dot com We have compiled the latest CVS snapshot (http://snaps.php.net/php5.2-latest.tar.gz) on Linux kernel 2.6.9-42.plus.c4 (Centos 4) as apache2 module with no luck. We have used just the most basic configuration (--with-apxs2=/wwwroot/bin/apxs). We have been able to reproduce the bug with 2 virtualhost, one with php_value and another one with php_admin_value. As soon as we load the one with php_admin_value, the include_path of the first one starts to randomly fail. We have a serious problem with this bug, since we are developing an application with Zend Framework (Did you realize how seriously this bug affects Zend Framework MVC (Zend/Loader.php / loadFile (#125))? It just doesn't work at all because of the bug). Hope to see this bug solved soon. [2008-02-07 00:56:08] manuel at mausz dot at There's no need to test this. I can still see the bug in CVS. Look at zend_ini.c: ini_entry-modifiable gets modified (... = ZEND_INI_SYSTEM) and won't get restored after the request has been processed (zend_restore_ini_entry_cb). [2008-02-07 00:47:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi Just to be sure this isn't fixed already. There were some changes done but I'm not sure anymore if those actually went into 5.2.5 and I don't have Apache setup around to test right now.. 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: it at inmolinkmls dot com Reported By: root at net1 dot cc Status: No Feedback Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: We have compiled the latest CVS snapshot (http://snaps.php.net/php5.2-latest.tar.gz) on Linux kernel 2.6.9-42.plus.c4 (Centos 4) as apache2 module with no luck. We have used just the most basic configuration (--with-apxs2=/wwwroot/bin/apxs). We have been able to reproduce the bug with 2 virtualhost, one with php_value and another one with php_admin_value. As soon as we load the one with php_admin_value, the include_path of the first one starts to randomly fail. We have a serious problem with this bug, since we are developing an application with Zend Framework (Did you realize how seriously this bug affects Zend Framework MVC (Zend/Loader.php / loadFile (#125))? It just doesn't work at all because of the bug). Hope to see this bug solved soon. Previous Comments: [2008-02-14 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2008-02-07 00:56:08] manuel at mausz dot at There's no need to test this. I can still see the bug in CVS. Look at zend_ini.c: ini_entry-modifiable gets modified (... = ZEND_INI_SYSTEM) and won't get restored after the request has been processed (zend_restore_ini_entry_cb). [2008-02-07 00:47:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi Just to be sure this isn't fixed already. There were some changes done but I'm not sure anymore if those actually went into 5.2.5 and I don't have Apache setup around to test right now.. [2008-02-07 00:45:48] [EMAIL PROTECTED] See also bug #43755 [2008-02-05 13:06:41] manuel at mausz dot at Can someone please assign this bug to some dev or commit my first patch for 5.3 and HEAD. This bug is annoying and I don't want to see it in 5.3 again. 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: manuel at mausz dot at Reported By: root at net1 dot cc Status: No Feedback Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: As there was no CVS commit the bug is still not fixed. I also tried to contact Antony who is responsible for the code which caused this bug but he don't have time atm. So can someone please change the bug to open again? - I'm not the author. Previous Comments: [2008-02-14 12:06:42] it at inmolinkmls dot com We have compiled the latest CVS snapshot (http://snaps.php.net/php5.2-latest.tar.gz) on Linux kernel 2.6.9-42.plus.c4 (Centos 4) as apache2 module with no luck. We have used just the most basic configuration (--with-apxs2=/wwwroot/bin/apxs). We have been able to reproduce the bug with 2 virtualhost, one with php_value and another one with php_admin_value. As soon as we load the one with php_admin_value, the include_path of the first one starts to randomly fail. We have a serious problem with this bug, since we are developing an application with Zend Framework (Did you realize how seriously this bug affects Zend Framework MVC (Zend/Loader.php / loadFile (#125))? It just doesn't work at all because of the bug). Hope to see this bug solved soon. [2008-02-14 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2008-02-07 00:56:08] manuel at mausz dot at There's no need to test this. I can still see the bug in CVS. Look at zend_ini.c: ini_entry-modifiable gets modified (... = ZEND_INI_SYSTEM) and won't get restored after the request has been processed (zend_restore_ini_entry_cb). [2008-02-07 00:47:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi Just to be sure this isn't fixed already. There were some changes done but I'm not sure anymore if those actually went into 5.2.5 and I don't have Apache setup around to test right now.. [2008-02-07 00:45:48] [EMAIL PROTECTED] See also bug #43755 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: jas8522 at gmail dot com Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: Indeed, this is definitely still a problem ... We've been using PHP on many live servers for quite a few years and not once have I needed to comment in a bug report because of an issue seriously affecting functionality. I would think that might help to show that this affects more than just a few users here and there. Previous Comments: [2008-02-14 15:11:03] root at net1 dot cc This issue is still open! [2008-02-14 13:05:22] manuel at mausz dot at As there was no CVS commit the bug is still not fixed. I also tried to contact Antony who is responsible for the code which caused this bug but he don't have time atm. So can someone please change the bug to open again? - I'm not the author. [2008-02-14 12:06:42] it at inmolinkmls dot com We have compiled the latest CVS snapshot (http://snaps.php.net/php5.2-latest.tar.gz) on Linux kernel 2.6.9-42.plus.c4 (Centos 4) as apache2 module with no luck. We have used just the most basic configuration (--with-apxs2=/wwwroot/bin/apxs). We have been able to reproduce the bug with 2 virtualhost, one with php_value and another one with php_admin_value. As soon as we load the one with php_admin_value, the include_path of the first one starts to randomly fail. We have a serious problem with this bug, since we are developing an application with Zend Framework (Did you realize how seriously this bug affects Zend Framework MVC (Zend/Loader.php / loadFile (#125))? It just doesn't work at all because of the bug). Hope to see this bug solved soon. [2008-02-14 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2008-02-07 00:56:08] manuel at mausz dot at There's no need to test this. I can still see the bug in CVS. Look at zend_ini.c: ini_entry-modifiable gets modified (... = ZEND_INI_SYSTEM) and won't get restored after the request has been processed (zend_restore_ini_entry_cb). 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: manuel at mausz dot at Reported By: root at net1 dot cc Status: Feedback Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: There's no need to test this. I can still see the bug in CVS. Look at zend_ini.c: ini_entry-modifiable gets modified (... = ZEND_INI_SYSTEM) and won't get restored after the request has been processed (zend_restore_ini_entry_cb). Previous Comments: [2008-02-07 00:47:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi Just to be sure this isn't fixed already. There were some changes done but I'm not sure anymore if those actually went into 5.2.5 and I don't have Apache setup around to test right now.. [2008-02-07 00:45:48] [EMAIL PROTECTED] See also bug #43755 [2008-02-05 13:06:41] manuel at mausz dot at Can someone please assign this bug to some dev or commit my first patch for 5.3 and HEAD. This bug is annoying and I don't want to see it in 5.3 again. [2008-01-22 10:32:59] phpbugs at afilas dot nl I have the same problem here with Apache 1.3 and FreeBSD 6.2. I am wondering why there is no response from the PHP dev team on this issue, as this a fairly serious issue IMHO. I chose to downgrade to 5.2.4 for the time being, hoping that this issue is fixed in 5.2.6. [2008-01-21 18:37:21] manuel at mausz dot at As I said before, my patch breaks the ini settings abi resulting in segfaults if old extensions are loaded. Due to the fact that one of my customers is using a proprietary extension I have implemented an alternate, dirty but hopefully non-breaking patch. The patch stores the original value 3 bits to the left of the new value. This method won't break any php or pecl extensions (all checked). Only ext/reflection needs to be recompiled. http://manuel.mausz.at/coding/patches/php/5.2.5/php5.2.5-restore-ini-level2.patch 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: manuel at mausz dot at Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: Can someone please assign this bug to some dev or commit my first patch for 5.3 and HEAD. This bug is annoying and I don't want to see it in 5.3 again. Previous Comments: [2008-01-22 10:32:59] phpbugs at afilas dot nl I have the same problem here with Apache 1.3 and FreeBSD 6.2. I am wondering why there is no response from the PHP dev team on this issue, as this a fairly serious issue IMHO. I chose to downgrade to 5.2.4 for the time being, hoping that this issue is fixed in 5.2.6. [2008-01-21 18:37:21] manuel at mausz dot at As I said before, my patch breaks the ini settings abi resulting in segfaults if old extensions are loaded. Due to the fact that one of my customers is using a proprietary extension I have implemented an alternate, dirty but hopefully non-breaking patch. The patch stores the original value 3 bits to the left of the new value. This method won't break any php or pecl extensions (all checked). Only ext/reflection needs to be recompiled. http://manuel.mausz.at/coding/patches/php/5.2.5/php5.2.5-restore-ini-level2.patch [2008-01-20 11:22:55] thorvath at fullnet dot hu I have the same problem on FreeBSD 6.1 with php5-5.2.5, tried to patch with the FreeBSD patch above, recompiled all modules, when I load php5_module apache sigfaults with 11 and core dumps, I use the apache22 port. [2008-01-19 15:56:00] scott at atomicrocketturtle dot com Testing this patch against 5.2.5, ioncube-loader and zend-optimizer will cause segmentation faults. Similar result with eaccelerator, which was resolved with a rebuild. [2008-01-17 16:52:48] d at tpyo dot net Thanks Manuel. Patch works perfectly. But I agree, it is a fairly serious issue that undoubtedly affects a lot of users. 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: phpbugs at afilas dot nl Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: I have the same problem here with Apache 1.3 and FreeBSD 6.2. I am wondering why there is no response from the PHP dev team on this issue, as this a fairly serious issue IMHO. I chose to downgrade to 5.2.4 for the time being, hoping that this issue is fixed in 5.2.6. Previous Comments: [2008-01-21 18:37:21] manuel at mausz dot at As I said before, my patch breaks the ini settings abi resulting in segfaults if old extensions are loaded. Due to the fact that one of my customers is using a proprietary extension I have implemented an alternate, dirty but hopefully non-breaking patch. The patch stores the original value 3 bits to the left of the new value. This method won't break any php or pecl extensions (all checked). Only ext/reflection needs to be recompiled. http://manuel.mausz.at/coding/patches/php/5.2.5/php5.2.5-restore-ini-level2.patch [2008-01-20 11:22:55] thorvath at fullnet dot hu I have the same problem on FreeBSD 6.1 with php5-5.2.5, tried to patch with the FreeBSD patch above, recompiled all modules, when I load php5_module apache sigfaults with 11 and core dumps, I use the apache22 port. [2008-01-19 15:56:00] scott at atomicrocketturtle dot com Testing this patch against 5.2.5, ioncube-loader and zend-optimizer will cause segmentation faults. Similar result with eaccelerator, which was resolved with a rebuild. [2008-01-17 16:52:48] d at tpyo dot net Thanks Manuel. Patch works perfectly. But I agree, it is a fairly serious issue that undoubtedly affects a lot of users. [2008-01-17 13:40:04] manuel at mausz dot at Err... php as apache module... :) 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: manuel at mausz dot at Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: As I said before, my patch breaks the ini settings abi resulting in segfaults if old extensions are loaded. Due to the fact that one of my customers is using a proprietary extension I have implemented an alternate, dirty but hopefully non-breaking patch. The patch stores the original value 3 bits to the left of the new value. This method won't break any php or pecl extensions (all checked). Only ext/reflection needs to be recompiled. http://manuel.mausz.at/coding/patches/php/5.2.5/php5.2.5-restore-ini-level2.patch Previous Comments: [2008-01-20 11:22:55] thorvath at fullnet dot hu I have the same problem on FreeBSD 6.1 with php5-5.2.5, tried to patch with the FreeBSD patch above, recompiled all modules, when I load php5_module apache sigfaults with 11 and core dumps, I use the apache22 port. [2008-01-19 15:56:00] scott at atomicrocketturtle dot com Testing this patch against 5.2.5, ioncube-loader and zend-optimizer will cause segmentation faults. Similar result with eaccelerator, which was resolved with a rebuild. [2008-01-17 16:52:48] d at tpyo dot net Thanks Manuel. Patch works perfectly. But I agree, it is a fairly serious issue that undoubtedly affects a lot of users. [2008-01-17 13:40:04] manuel at mausz dot at Err... php as apache module... :) [2008-01-17 13:35:48] manuel at mausz dot at Can some dev please take a look at this (or the patch)? This is a serious issue for all users running apache as module and mixing php_admin_value and php_value. It also looks like this is the same as: http://bugs.php.net/bug.php?id=43842 http://bugs.php.net/bug.php?id=43755 http://bugs.php.net/bug.php?id=43207 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: thorvath at fullnet dot hu Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: I have the same problem on FreeBSD 6.1 with php5-5.2.5, tried to patch with the FreeBSD patch above, recompiled all modules, when I load php5_module apache sigfaults with 11 and core dumps, I use the apache22 port. Previous Comments: [2008-01-19 15:56:00] scott at atomicrocketturtle dot com Testing this patch against 5.2.5, ioncube-loader and zend-optimizer will cause segmentation faults. Similar result with eaccelerator, which was resolved with a rebuild. [2008-01-17 16:52:48] d at tpyo dot net Thanks Manuel. Patch works perfectly. But I agree, it is a fairly serious issue that undoubtedly affects a lot of users. [2008-01-17 13:40:04] manuel at mausz dot at Err... php as apache module... :) [2008-01-17 13:35:48] manuel at mausz dot at Can some dev please take a look at this (or the patch)? This is a serious issue for all users running apache as module and mixing php_admin_value and php_value. It also looks like this is the same as: http://bugs.php.net/bug.php?id=43842 http://bugs.php.net/bug.php?id=43755 http://bugs.php.net/bug.php?id=43207 [2008-01-13 03:14:53] root at net1 dot cc I've been using the patched PHP for several hours now, and - confirmed - it's working flawless! This patch really fixes the issue! Thanks once again, Manuel! For FreeBSD users, I've uploaded a modified patch file for deployment with the ports system, for ease of use, and instructions here: http://mirror.net1.cc/projects/php-bug43677-patch/ 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: scott at atomicrocketturtle dot com Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: Testing this patch against 5.2.5, ioncube-loader and zend-optimizer will cause segmentation faults. Similar result with eaccelerator, which was resolved with a rebuild. Previous Comments: [2008-01-17 16:52:48] d at tpyo dot net Thanks Manuel. Patch works perfectly. But I agree, it is a fairly serious issue that undoubtedly affects a lot of users. [2008-01-17 13:40:04] manuel at mausz dot at Err... php as apache module... :) [2008-01-17 13:35:48] manuel at mausz dot at Can some dev please take a look at this (or the patch)? This is a serious issue for all users running apache as module and mixing php_admin_value and php_value. It also looks like this is the same as: http://bugs.php.net/bug.php?id=43842 http://bugs.php.net/bug.php?id=43755 http://bugs.php.net/bug.php?id=43207 [2008-01-13 03:14:53] root at net1 dot cc I've been using the patched PHP for several hours now, and - confirmed - it's working flawless! This patch really fixes the issue! Thanks once again, Manuel! For FreeBSD users, I've uploaded a modified patch file for deployment with the ports system, for ease of use, and instructions here: http://mirror.net1.cc/projects/php-bug43677-patch/ [2008-01-12 21:19:29] root at net1 dot cc I'm gonna test Manuel's patch (thanks!) and report back later if it does fix the problems observed. 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: manuel at mausz dot at Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: Can some dev please take a look at this (or the patch)? This is a serious issue for all users running apache as module and mixing php_admin_value and php_value. It also looks like this is the same as: http://bugs.php.net/bug.php?id=43842 http://bugs.php.net/bug.php?id=43755 http://bugs.php.net/bug.php?id=43207 Previous Comments: [2008-01-13 03:14:53] root at net1 dot cc I've been using the patched PHP for several hours now, and - confirmed - it's working flawless! This patch really fixes the issue! Thanks once again, Manuel! For FreeBSD users, I've uploaded a modified patch file for deployment with the ports system, for ease of use, and instructions here: http://mirror.net1.cc/projects/php-bug43677-patch/ [2008-01-12 21:19:29] root at net1 dot cc I'm gonna test Manuel's patch (thanks!) and report back later if it does fix the problems observed. [2008-01-12 18:08:43] manuel at mausz dot at I tracked the problem down. Every altered ini setting gets added to the modified_ini_directives-hashtable in order to restore the original value after the request has been processed. Zend simply forgets to restore the modifiable-level. A patch can be found at http://manuel.mausz.at/coding/patches/php/5.2.5/php5.2.5-restore-ini-level.patch Please note that this patch will break the ini setting ABI. Thus all extensions registering ini settings will have to be recompiled. [2008-01-07 22:57:03] root at net1 dot cc Digging some more into that, I've found the problem to be in the Apache/PHP interpretation of the configured VirtualHost. First, the problem only exists if we do have *both* VirtualHost(s) with 'php_admin_value include_path' *and* another VirtualHost(s)with 'php_value include_path'. If all our VirtualHosts use 'php_value' only, it's behaving as usual. Experimenting with this shows that, after an Apache startup/reload, things work OK. Then, they start to randomly fail until some time later 100% of the requests fail to work OK. Looking at the Apache logs, the problem (according to me) is that the PHP module behaves strange when it sees the php_admin_value variable. Let's say we have this config (not a working one, just to give you the idea): VirtualHost *:80 ServerName test1.dot.com php_value include_path .:/test1 /VirtualHost VirtualHost *:80 ServerName test2.dot.com php_admin_value include_path .:/test2 /VirtualHost We fire up Apache, and start accessing test1.dot.com pages *only*. Everything works fine. *But* when we start to simultaneously access test2.dot.com, the test1.dot.com pages start to fail more and more (due to the incorrect include_path). Monitoring which Apache process servers each page reveals that *when* a process serves a page for test2.dot.com, it reads the 'php_admin_value' for it, sets it up, and refuses to change the include_path from further config lines, *even* if they are from the config of the virtual host of a *new* request. That is - once an Apache process servers a page for a VirtualHost with php_admin_value, all consequent requests served by the same process are processed with that php_admin_value, regardless of their config. The *solution* , though insecure, is to change *all* your 'php_admin_value include_path' lines to 'php_value include_path'. I would very much like to see this fixed (though I'm completely unaware of the way Apache/PHP configuration is parsed), and will provide more feedback if needed. [2008-01-07 20:57:58] tborgans at gmx dot de same problem here on linux with 5.2.5, apache 1.3.39 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: manuel at mausz dot at Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: Err... php as apache module... :) Previous Comments: [2008-01-17 13:35:48] manuel at mausz dot at Can some dev please take a look at this (or the patch)? This is a serious issue for all users running apache as module and mixing php_admin_value and php_value. It also looks like this is the same as: http://bugs.php.net/bug.php?id=43842 http://bugs.php.net/bug.php?id=43755 http://bugs.php.net/bug.php?id=43207 [2008-01-13 03:14:53] root at net1 dot cc I've been using the patched PHP for several hours now, and - confirmed - it's working flawless! This patch really fixes the issue! Thanks once again, Manuel! For FreeBSD users, I've uploaded a modified patch file for deployment with the ports system, for ease of use, and instructions here: http://mirror.net1.cc/projects/php-bug43677-patch/ [2008-01-12 21:19:29] root at net1 dot cc I'm gonna test Manuel's patch (thanks!) and report back later if it does fix the problems observed. [2008-01-12 18:08:43] manuel at mausz dot at I tracked the problem down. Every altered ini setting gets added to the modified_ini_directives-hashtable in order to restore the original value after the request has been processed. Zend simply forgets to restore the modifiable-level. A patch can be found at http://manuel.mausz.at/coding/patches/php/5.2.5/php5.2.5-restore-ini-level.patch Please note that this patch will break the ini setting ABI. Thus all extensions registering ini settings will have to be recompiled. [2008-01-07 22:57:03] root at net1 dot cc Digging some more into that, I've found the problem to be in the Apache/PHP interpretation of the configured VirtualHost. First, the problem only exists if we do have *both* VirtualHost(s) with 'php_admin_value include_path' *and* another VirtualHost(s)with 'php_value include_path'. If all our VirtualHosts use 'php_value' only, it's behaving as usual. Experimenting with this shows that, after an Apache startup/reload, things work OK. Then, they start to randomly fail until some time later 100% of the requests fail to work OK. Looking at the Apache logs, the problem (according to me) is that the PHP module behaves strange when it sees the php_admin_value variable. Let's say we have this config (not a working one, just to give you the idea): VirtualHost *:80 ServerName test1.dot.com php_value include_path .:/test1 /VirtualHost VirtualHost *:80 ServerName test2.dot.com php_admin_value include_path .:/test2 /VirtualHost We fire up Apache, and start accessing test1.dot.com pages *only*. Everything works fine. *But* when we start to simultaneously access test2.dot.com, the test1.dot.com pages start to fail more and more (due to the incorrect include_path). Monitoring which Apache process servers each page reveals that *when* a process serves a page for test2.dot.com, it reads the 'php_admin_value' for it, sets it up, and refuses to change the include_path from further config lines, *even* if they are from the config of the virtual host of a *new* request. That is - once an Apache process servers a page for a VirtualHost with php_admin_value, all consequent requests served by the same process are processed with that php_admin_value, regardless of their config. The *solution* , though insecure, is to change *all* your 'php_admin_value include_path' lines to 'php_value include_path'. I would very much like to see this fixed (though I'm completely unaware of the way Apache/PHP configuration is parsed), and will provide more feedback if needed. 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: d at tpyo dot net Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: Thanks Manuel. Patch works perfectly. But I agree, it is a fairly serious issue that undoubtedly affects a lot of users. Previous Comments: [2008-01-17 13:40:04] manuel at mausz dot at Err... php as apache module... :) [2008-01-17 13:35:48] manuel at mausz dot at Can some dev please take a look at this (or the patch)? This is a serious issue for all users running apache as module and mixing php_admin_value and php_value. It also looks like this is the same as: http://bugs.php.net/bug.php?id=43842 http://bugs.php.net/bug.php?id=43755 http://bugs.php.net/bug.php?id=43207 [2008-01-13 03:14:53] root at net1 dot cc I've been using the patched PHP for several hours now, and - confirmed - it's working flawless! This patch really fixes the issue! Thanks once again, Manuel! For FreeBSD users, I've uploaded a modified patch file for deployment with the ports system, for ease of use, and instructions here: http://mirror.net1.cc/projects/php-bug43677-patch/ [2008-01-12 21:19:29] root at net1 dot cc I'm gonna test Manuel's patch (thanks!) and report back later if it does fix the problems observed. [2008-01-12 18:08:43] manuel at mausz dot at I tracked the problem down. Every altered ini setting gets added to the modified_ini_directives-hashtable in order to restore the original value after the request has been processed. Zend simply forgets to restore the modifiable-level. A patch can be found at http://manuel.mausz.at/coding/patches/php/5.2.5/php5.2.5-restore-ini-level.patch Please note that this patch will break the ini setting ABI. Thus all extensions registering ini settings will have to be recompiled. 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: manuel at mausz dot at Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: I tracked the problem down. Every altered ini setting gets added to the modified_ini_directives-hashtable in order to restore the original value after the request has been processed. Zend simply forgets to restore the modifiable-level. A patch can be found at http://manuel.mausz.at/coding/patches/php/5.2.5/php5.2.5-restore-ini-level.patch Please note that this patch will break the ini setting ABI. Thus all extensions registering ini settings will have to be recompiled. Previous Comments: [2008-01-07 22:57:03] root at net1 dot cc Digging some more into that, I've found the problem to be in the Apache/PHP interpretation of the configured VirtualHost. First, the problem only exists if we do have *both* VirtualHost(s) with 'php_admin_value include_path' *and* another VirtualHost(s)with 'php_value include_path'. If all our VirtualHosts use 'php_value' only, it's behaving as usual. Experimenting with this shows that, after an Apache startup/reload, things work OK. Then, they start to randomly fail until some time later 100% of the requests fail to work OK. Looking at the Apache logs, the problem (according to me) is that the PHP module behaves strange when it sees the php_admin_value variable. Let's say we have this config (not a working one, just to give you the idea): VirtualHost *:80 ServerName test1.dot.com php_value include_path .:/test1 /VirtualHost VirtualHost *:80 ServerName test2.dot.com php_admin_value include_path .:/test2 /VirtualHost We fire up Apache, and start accessing test1.dot.com pages *only*. Everything works fine. *But* when we start to simultaneously access test2.dot.com, the test1.dot.com pages start to fail more and more (due to the incorrect include_path). Monitoring which Apache process servers each page reveals that *when* a process serves a page for test2.dot.com, it reads the 'php_admin_value' for it, sets it up, and refuses to change the include_path from further config lines, *even* if they are from the config of the virtual host of a *new* request. That is - once an Apache process servers a page for a VirtualHost with php_admin_value, all consequent requests served by the same process are processed with that php_admin_value, regardless of their config. The *solution* , though insecure, is to change *all* your 'php_admin_value include_path' lines to 'php_value include_path'. I would very much like to see this fixed (though I'm completely unaware of the way Apache/PHP configuration is parsed), and will provide more feedback if needed. [2008-01-07 20:57:58] tborgans at gmx dot de same problem here on linux with 5.2.5, apache 1.3.39 [2008-01-06 21:38:14] d at tpyo dot net Noticed the same thing with 5.2.5 on Linux w/ Apache 2. I'm aware this is supposed to be the intended behaviour as of 5.2.5 but something is definitely breaking. It seems the include_path is being unset or ignored at some point. Haven't experienced this at random as described - once it breaks it doesn't correct itself until restarting Apache. Could be linked to the fix for bug #41561? [2007-12-26 01:47:49] root at net1 dot cc Description: PHP randomly assigns for the local include_path value the global one, not the one set with php_value, and, when it does assign the global value, it does not allow to use ini_set() to modify it (behaves like it was set with php_admin_value). Reproduce code: --- My default include path is .:/usr/local/share/pear. In the httpd.conf (btw, this is Apache 2.2.x), I have: php_value include_path .:/blabla There's a file 'test.php' which contains the following: ?php phpinfo(); ? Expected result: I open the test.php in a web browser and keep refreshing it. I expect it to show: include_path .:/blabla each time i refresh it Actual result: -- The results are random, once it shows: include_path .:/blabla once it shows: include_path .:/usr/local/share/pear -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: tborgans at gmx dot de Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: same problem here on linux with 5.2.5, apache 1.3.39 Previous Comments: [2008-01-06 21:38:14] d at tpyo dot net Noticed the same thing with 5.2.5 on Linux w/ Apache 2. I'm aware this is supposed to be the intended behaviour as of 5.2.5 but something is definitely breaking. It seems the include_path is being unset or ignored at some point. Haven't experienced this at random as described - once it breaks it doesn't correct itself until restarting Apache. Could be linked to the fix for bug #41561? [2007-12-26 01:47:49] root at net1 dot cc Description: PHP randomly assigns for the local include_path value the global one, not the one set with php_value, and, when it does assign the global value, it does not allow to use ini_set() to modify it (behaves like it was set with php_admin_value). Reproduce code: --- My default include path is .:/usr/local/share/pear. In the httpd.conf (btw, this is Apache 2.2.x), I have: php_value include_path .:/blabla There's a file 'test.php' which contains the following: ?php phpinfo(); ? Expected result: I open the test.php in a web browser and keep refreshing it. I expect it to show: include_path .:/blabla each time i refresh it Actual result: -- The results are random, once it shows: include_path .:/blabla once it shows: include_path .:/usr/local/share/pear -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: d at tpyo dot net Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: Noticed the same thing with 5.2.5 on Linux w/ Apache 2. I'm aware this is supposed to be the intended behaviour as of 5.2.5 but something is definitely breaking. It seems the include_path is being unset or ignored at some point. Haven't experienced this at random as described - once it breaks it doesn't correct itself until restarting Apache. Could be linked to the fix for bug #41561? Previous Comments: [2007-12-26 01:47:49] root at net1 dot cc Description: PHP randomly assigns for the local include_path value the global one, not the one set with php_value, and, when it does assign the global value, it does not allow to use ini_set() to modify it (behaves like it was set with php_admin_value). Reproduce code: --- My default include path is .:/usr/local/share/pear. In the httpd.conf (btw, this is Apache 2.2.x), I have: php_value include_path .:/blabla There's a file 'test.php' which contains the following: ?php phpinfo(); ? Expected result: I open the test.php in a web browser and keep refreshing it. I expect it to show: include_path .:/blabla each time i refresh it Actual result: -- The results are random, once it shows: include_path .:/blabla once it shows: include_path .:/usr/local/share/pear -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
