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?

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.

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.

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/

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

Err... php as apache module... :)

Thanks Manuel.  Patch works perfectly.  But I agree, it is a fairly 
serious issue that undoubtedly affects a lot of users.

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

See also bug #43755

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.

See also bug
http://bugs.php.net/bug.php?id=44178
which I now see describes the same behaviour.

Yes. The bug only occurs if you're mixing php_admin_value and php_value with the same ini-setting.

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.

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.