Might be related to bug 41561 (and related commits) when building with threads (I guess this is the case here).

I don't think this is a threading problem, as I'm running Apache 2.2.6 
under `prefork` mpm, and when I compiled (via gentoo USE flags -- not 
sure what the 'thread' use flag corresponds to in the ./configure), 
threads were disabled.  Also, the last comment on #41561 states that 
threads weren't involved and that it was patched in the CVS last week, 
and I've been experiencing this behavior on today's CVS snap.

This is my configure statement:

'./configure' '--prefix=/usr/lib/php5' '--host=i686-pc-linux-gnu' '--
mandir=/usr/lib/php5/man' '--infodir=/usr/lib/php5/info' '--
sysconfdir=/etc' '--cache-file=./config.cache' '--disable-cli' '--
with-apxs2=/usr/sbin/apxs2' '--with-config-file-path=/etc/php/apache2-
php5' '--with-config-file-scan-dir=/etc/php/apache2-php5/ext-active' 
'--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar' 
'--with-curl' '--without-curlwrappers' '--disable-dbase' '--disable-
exif' '--without-fbsql' '--without-fdftk' '--disable-filter' '--
disable-ftp' '--with-gettext' '--without-gmp' '--disable-hash' '--
without-iconv' '--disable-ipv6' '--disable-json' '--without-kerberos' 
'--enable-mbstring' '--with-mcrypt' '--without-mhash' '--without-msql' 
'--without-mssql' '--without-ncurses' '--with-openssl' '--with-
openssl-dir=/usr' '--disable-pcntl' '--disable-pdo' '--without-pgsql' 
'--without-pspell' '--without-recode' '--disable-reflection' '--
disable-simplexml' '--disable-shmop' '--without-snmp' '--disable-soap' 
'--disable-sockets' '--disable-spl' '--without-sybase' '--without-
sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm' 
'--without-tidy' '--disable-tokenizer' '--disable-wddx' '--disable-
xmlreader' '--disable-xmlwriter' '--without-xmlrpc' '--without-xsl' '-
-disable-zip' '--with-zlib' '--disable-debug' '--without-cdb' '--
without-db4' '--without-flatfile' '--without-gdbm' '--without-inifile' 
'--without-qdbm' '--without-freetype-dir' '--without-t1lib' '--
disable-gd-jis-conv' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--
without-xpm-dir' '--with-gd' '--with-mysql=/usr' '--with-mysql-
sock=/var/run/mysqld/mysqld.sock' '--without-mysqli' '--with-readline' 
'--without-libedit' '--without-mm' '--without-sqlite' '--with-pic'

I extended my reproduction code to check ini_set(), which suffers the 
same behavior.

Code:
<?php
var_dump(error_reporting());

var_dump(error_reporting(E_ALL ^ E_NOTICE ^ E_USER_NOTICE));
trigger_error('This should not be seen', E_USER_NOTICE);
echo $a; // should cause a notice
var_dump(error_reporting());

var_dump(ini_set('error_reporting', E_ALL ^ E_NOTICE ^ E_USER_NOTICE ^ 
E_USER_WARNING));
var_dump(error_reporting());
trigger_error('This should not be seen', E_USER_NOTICE);
echo $a; // should cause a notice
var_dump(error_reporting());
?>


Output:
int(6143) int(6143)
Notice: This should not be seen in 
/home/gabebug/public_html/error_reporting_tests.php on line 5

Notice: Undefined variable: a in 
/home/gabebug/public_html/error_reporting_tests.php on line 6
int(6143) bool(false) int(6143)
Notice: This should not be seen in 
/home/gabebug/public_html/error_reporting_tests.php on line 11

Notice: Undefined variable: a in 
/home/gabebug/public_html/error_reporting_tests.php on line 12
int(6143)

In the comments of the other bug, this is mentioned:

>When error_reporting was overwritten with ADMIN privileges it cannot be 
changed anymore by the @ operator :)

If I add something like:
@include 'doesnotexist';

at the end of the test file, no warning will be issued even when the 
problem behavior is occurring.  Usage of the '@' symbol for error 
suppression is completely unaffected by this bug.

Is it just error_reporting ini option you get this problem with?
It is a bit hard to debug, the ini system being what it is..

Do you use php_admin_* flags anywhere in your httpd.conf (or included parts of it) ??

I have some vhosts that have the following within the <VirtualHost> 
block:
php_admin_value error_reporting "E_ALL ^ E_NOTICE"

However, this problem is occurring on a vhost that does not use any 
php_admin_values, either globally or in the <VirtualHost> block.

I have not had troubles overriding any of the other .ini values that I 
know of.  I have a few sites that have the following .htaccess:
php_flag short_open_tag on
php_flag register_globals on
php_value error_reporting "E_ALL ^ E_NOTICE"

During page loads when the error_reporting doesn't get properly 
overwritten with the new value, the short_open_tag and 
register_globals are always properly set and are not suffering the 
same problem. A good portion of my sites also change the include_path 
via ini_set(), and I haven't had a single issue with any of those.  It 
appears that this is specific to the error_reporting ini value and 
isn't affecting any of the other ini values.

It should be noted that sites that use a php_admin_value 
error_reporting in a <VirtualHost> block have been reported (yet?) to 
have any issues with setting a new local value.

I've been running a httperf on a sample script testing when setting 
error_reporting in a <VirtualHost> block via php_admin_value vs. 
php_value and watching the error log.

php_admin_value does NOT have problems setting the level
php_value DOES have problems setting the level

What MPM is used in Apache? Note: php_admin_* sets the ini option not to be modifiable by .htaccess or in scripts using ini_set().
Can you try and create a small test environment with this information?
We need sample config to be able to reproduce this ourselves. Apparently it's some .htaccess file and/or script changing error_reporting() using either ini_set() or error_reporting() for it.
Also using @ affects it..

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".

I have not been keep track of this bug since it was originally reported, 
I can no longer reproduce the behavior as of php-5.2.6

appears to have been fixed prior to php-5.2.6