# bad test case that depends on user local ini - Thread: https://externals.io/message/34275 - Original archive: https://news-web.php.net/php.internals/34275 - Started by phpxcache on 2007-12-30T03:16:02+00:00 - Messages: 7 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #34275 — phpxcache — 2007-12-30T03:16:02+00:00 URL: https://externals.io/message/34275#34275 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? --- ## #34279 — Jani Taskinen — 2007-12-30T11:31:19+00:00 URL: https://externals.io/message/34275#34279 · In reply to: #34275 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 100M > > is it expected that the test case should depends on users' ini settings? > -- Patches/Donations: http://pecl.php.net/~jani/ --- ## #34281 — Christian Hoffmann — 2007-12-30T13:47:25+00:00 URL: https://externals.io/message/34275#34281 · In reply to: #34275 > 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. [1] http://bugs.php.net/43128 -- Christian Hoffmann --- ## #34290 — Jani Taskinen — 2007-12-31T11:39:53+00:00 URL: https://externals.io/message/34275#34290 · In reply to: #34281 > 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/ --- ## #34292 — Jani Taskinen — 2007-12-31T11:44:10+00:00 URL: https://externals.io/message/34275#34292 · In reply to: #34281 > 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/ --- ## #34300 — Christian Hoffmann — 2007-12-31T13:53:50+00:00 URL: https://externals.io/message/34275#34300 · In reply to: #34292 > 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. > > > […] > > 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 --- ## #35979 — Christian Hoffmann — 2008-03-05T19:43:50+00:00 URL: https://externals.io/message/34275#35979 · In reply to: #34300 > 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