ID: 42749
User updated by: gabe at mudbugmedia dot com
Reported By: gabe at mudbugmedia dot com
Status: Open
Bug Type: *General Issues
Operating System: Linux proto 2.6.20-hardened-r5
PHP Version: 5CVS-2007-09-24 (snap)
New Comment:
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
Previous Comments:
------------------------------------------------------------------------
[2007-09-25 14:01:03] gabe at mudbugmedia dot com
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.
------------------------------------------------------------------------
[2007-09-25 09:20:53] [EMAIL PROTECTED]
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) ??
------------------------------------------------------------------------
[2007-09-24 21:02:55] gabe at mudbugmedia dot com
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.
------------------------------------------------------------------------
[2007-09-24 20:56:17] gabe at mudbugmedia dot com
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)
------------------------------------------------------------------------
[2007-09-24 20:54:00] gabe at mudbugmedia dot com
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'
------------------------------------------------------------------------
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/42749
--
Edit this bug report at http://bugs.php.net/?id=42749&edit=1
