i have the following settings in my /etc/php.ini
pcre.backtrack_limit=10000
pcre.recursion_limit=10000000
test case
ini_get_all() tests [ext/standard/tests/general_functions/ini_get_all.phpt]
FAIL. but after i remove the settings, it will PASS.
Bug #43128 Very long class name causes segfault [Zend/tests/bug43128.phpt]
also FAIL because i have memory_limit set to 50M in /etc/php.ini, PASS
if i set it to 100M
is it expected that the test case should depends on users' ini settings?
These both tests should just have the INI section with proper settings.
--Jani
i have the following settings in my /etc/php.ini
pcre.backtrack_limit=10000
pcre.recursion_limit=10000000
test case
ini_get_all()tests [ext/standard/tests/general_functions/ini_get_all.phpt]
FAIL. but after i remove the settings, it will PASS.Bug #43128 Very long class name causes segfault [Zend/tests/bug43128.phpt]
also FAIL because i have memory_limit set to 50M in /etc/php.ini, PASS
if i set it to 100Mis it expected that the test case should depends on users' ini settings?
--
Patches/Donations: http://pecl.php.net/~jani/
i have the following settings in my /etc/php.ini
pcre.backtrack_limit=10000
pcre.recursion_limit=10000000
test case
ini_get_all()tests [ext/standard/tests/general_functions/ini_get_all.phpt]
FAIL. but after i remove the settings, it will PASS.Bug #43128 Very long class name causes segfault [Zend/tests/bug43128.phpt]
also FAIL because i have memory_limit set to 50M in /etc/php.ini, PASS
if i set it to 100M
You should not blame php.net devs in case of bug 43128 [1], as the
relevant security patch which adds this test has not been committed to
the official stable branch, looks like only 5.3+ will have the fix. So,
sadly, this patch + test is Gentoo-specific at the moment.
Sadly, to verify if the problem is fixed (that's what the test case is
supposed to check) requires pretty long strings, so a high memory limit
might be needed.
is it expected that the test case should depends on users' ini settings?
I asked that myself several times as well. It seems wrong to me to use
global php.ini files when running tests for a possibly completely
unrelated build. Last time I asked on IRC, the "solution" was to fix
those tests to hardcode the needed ini settings in the --INI-- section.
While this fixes the problem itself, it still leaves certain other
problems unfixed. Just consider the following scenario: You've got an
existing PHP installation. Let's assume you are using Apache w/ a
multi-threaded mpm and as such have built php with zts. All your
extensions are built with zend thread safety as well, of course. Then
you decide that switching to another web server and using FastCGI might
be better, as such you turn off zts for the new build as you don't need
it anymore. Building works fine, but suddenly almost all tests are
starting to fail. Why? Because run-tests.php uses the global php.ini
file and tries to load your zts extensions which cannot work for obvious
reasons.
IMO, make test is supposed to test the PHP install which is going to be
installed, not some parts of the new PHP install and some parts of the
old configuration.
As such, we (in case of Gentoo/php) are replacing all calls to the php
cli binary with calls to "php -n". Now make test does what we want, we
are happy, the user is happy, everone is happy.
I offered the necessary patches multiple times, but noone wanted them.
I'd be happy to know what php developers would suggest as a proper fix
for this problem, if they consider "php -n" wrong.
--
Christian Hoffmann
I'd be happy to know what php developers would suggest as a proper fix
for this problem, if they consider "php -n" wrong.
We have caught several actual bugs because of NOT using -n as people
have had exotic settings not included in the stock php.ini files.
--
Patches/Donations: http://pecl.php.net/~jani/
problems unfixed. Just consider the following scenario: You've got an
existing PHP installation. Let's assume you are using Apache w/ a
multi-threaded mpm and as such have built php with zts. All your
extensions are built with zend thread safety as well, of course. Then
you decide that switching to another web server and using FastCGI might
be better, as such you turn off zts for the new build as you don't need
it anymore. Building works fine, but suddenly almost all tests are
starting to fail. Why? Because run-tests.php uses the global php.ini
file and tries to load your zts extensions which cannot work for obvious
reasons.
But then the installed php wouldn't work either unless you fix the
php.ini first. :)
Besides, the 'make test' does NOT include the extension lines from the
php.ini. I added a fix for this long time ago to only load those shared
extensions which were currently build. Not sure in what PHP version it
was included in..but it is in the current PHP_5_2 branch.
--Jani
--
Patches/Donations: http://pecl.php.net/~jani/
We have caught several actual bugs because of NOT using -n as people
have had exotic settings not included in the stock php.ini files.
I've never doubt that. It certainly has its advantages as well.
problems unfixed. Just consider the following scenario: You've got an
existing PHP installation. Let's assume you are using Apache w/ a
multi-threaded mpm and as such have built php with zts. All your
extensions are built with zend thread safety as well, of course. Then
you decide that switching to another web server and using FastCGI might
be better, as such you turn off zts for the new build as you don't need
it anymore. Building works fine, but suddenly almost all tests are
starting to fail. Why? Because run-tests.php uses the global php.ini
file and tries to load your zts extensions which cannot work for obvious
reasons.But then the installed php wouldn't work either unless you fix the
php.ini first. :)
That's right. Either you have to keep in mind to fix it before really
starting your new setup, or you can have some pseudo-automatic config
file updating.
If you think that case is rather uncommon -- ok, then imagine you are
simply testing for regressions and playing with zts/non-zts or
debug/non-debug while doing so. You don't even have to install the
resulting binaries, just run run-tests.php. :)
Besides, the 'make test' does NOT include the extension lines from the
php.ini. I added a fix for this long time ago to only load those shared
extensions which were currently build. Not sure in what PHP version it
was included in..but it is in the current PHP_5_2 branch.
You are right. I've never noticed that as we are loading extensions in
seperate ini files, i.e. we are using --with-config-file-scan-dir. It
looks like this case isn't accounted for in make test and I do not see
an easy way to do so.
So, sorry for implying that it is broken on a general level, it seems to
cause problems only when using --with-config-file-scan-dir. Do you have
any suggestions / possible fixes for that case by chance?
There is another problem though: Tests which spawn their own php
interpreter (such as Zend/tests/bug40236.phpt) do not load tmp-php.ini
but use the global ini file which does contain extension* directives.
These tests break.
If these two "edge" case were fixed, I'd be perfectly happy with the
fact that basically a global php.ini file is used.
--
Christian Hoffmann
There is another problem though: Tests which spawn their own php
interpreter (such as Zend/tests/bug40236.phpt) do not load tmp-php.ini
but use the global ini file which does contain extension* directives.
These tests break.
Ok, meanwhile I went through (hopefully) all test cases which spawn
their own PHP interpreter and made them use -n (as most of those tests
already do anyway).
Would committing this patch [1] be a valid compromise?
I've yet another patch [2] which makes run-tests.php PHP calls (for
determining PHP version etc.) use -n as well. The actual tests are still
run with whatever arguments the user supplies to run-tests.php itself.
If those patches could be applied, it would really be nice. Average
users would still test with the global php ini to catch any regressions
/ ini-specific bugs, while distributions could easily force usage of no
php.ini by simply passing -n as argument to run-tests.php.
[1] http://home.hoffie.info/php_tests-ignore-php-ini.patch
[2] http://home.hoffie.info/php_run-tests-ignore-php-ini.patch
--
Christian Hoffmann