Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34281
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain gentoo.org does not designate 217.20.118.221 as permitted sender)
Message-ID: <4777A16D.9090309@gentoo.org>
Date: Sun, 30 Dec 2007 14:47:25 +0100
User-Agent: Thunderbird 2.0.0.9 (X11/20071211)
MIME-Version: 1.0
To: phpxcache <phpxcache@gmail.com>
CC: php-dev List <internals@lists.php.net>
References: <28139bc0712291916y2874424eg889334eeb462db81@mail.gmail.com>
In-Reply-To: <28139bc0712291916y2874424eg889334eeb462db81@mail.gmail.com>
OpenPGP: id=9CCF4998
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig0EF5B89F7509B65983E04619"
Subject: Re: [PHP-DEV] bad test case that depends on user local ini
From: hoffie@gentoo.org (Christian Hoffmann)

--------------enig0EF5B89F7509B65983E04619
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 2007-12-30 04:16, phpxcache wrote:
> i have the following settings in my /etc/php.ini
> pcre.backtrack_limit=3D10000
> pcre.recursion_limit=3D10000000
> test case
> ini_get_all() tests [ext/standard/tests/general_functions/ini_get_all.p=
hpt]
> FAIL. but after i remove the settings, it will PASS.
>=20
> Bug #43128 Very long class name causes segfault [Zend/tests/bug43128.ph=
pt]
> 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


--=20
Christian Hoffmann


--------------enig0EF5B89F7509B65983E04619
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkd3oXMACgkQJ9KLJlGHWYK3xQCfblZ1vd1R8iud+Lf2j5OB2VFY
fGsAnjswrKyDi1ox3ZSBTZbgcvR1cG6/
=E06f
-----END PGP SIGNATURE-----

--------------enig0EF5B89F7509B65983E04619--