-
Notifications
You must be signed in to change notification settings - Fork 7.9k
tests: add missing TEST_PHP_EXTRA_ARGS #11669
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Always passing |
I could replace the array argument to |
(In case that last comment is a bit mysterious, replacing the array with a string would make it easy to append |
887e262
to
59cc6c3
Compare
New version adds |
I broke something on Windows. Two of them are throwing,
which probably has something to do with
which very likely has arisen from the fact that we're now actually passing args to this PHP from,
If anyone actually has a Windows box and wants to just tell me WTF to do in the first two, it would save me a lot of guessing. The second I will have to think about. It's not immediately obvious why mysqli is failing for this one test but not others. |
884a92a
to
dde18ce
Compare
That seems to have done the trick without being too overcomplicated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those proc_open might need some changes.
try { | ||
proc_open([$php], [['redirect']], $pipes); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isn't this changing test from array syntax to shell syntax? If so, those are different things to test so it should not be changed. You should rather create array from $args
and pass it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, but how do we create an array from $args
? Am I overlooking an easy solution?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this seems to have stalled, the stated purpose of this file is not to test the syntax of proc_open()
, but instead to test that redirection works. While it does test the array syntax as a side effect, that's not the crucial part; so in my opinion it's reasonable to change the syntax to fix this unrelated issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good from my side. @bukka Were your concerns clarified? ext/standard/tests/general_functions/proc_open_array.phpt
is there to explicitly test the []
variant.
This test runs the PHP test executable from the command-line, but was not passing TEST_PHP_EXTRA_ARGS to it from run-tests.php. This commit adds the args, but also updates the test case. This test relies on memory_limit being updated by an INI file (generated on-the-fly), but by default, run-tests.php overrides PHP's memory_limit using TEST_PHP_EXTRA_ARGS. So if we pass the extra args to PHP, then the memory limit will be constant. To work around that, we switch to using max_input_vars (as opposed to memory_limit) inside the test.
Several of our proc_open() tests fail to pass TEST_PHP_EXTRA_ARGS to the PHP binary they execute. This can lead to spurious failures when, for example, the system's INI file is incompatible with the just-built CLI php: ---- ACTUAL OUTPUT array(1) { [2]=> resource(4) of type (stream) } string(123) "Failed loading /usr/lib64/php8.2/lib64/opcache.so: /usr/lib64/php8.2/lib64/opcache.so: undefined symbol: _emalloc_32 Error" Naturally we would like to pass TEST_PHP_EXTRA_ARGS to these invocations, after which "run-tests.php -n" would avoid loading the incompatible INI file. However, in this case, TEST_PHP_EXTRA_ARGS is a free-form environment variable, and proc_open() is being fed an array of arguments. It would be difficult to parse TEST_PHP_EXTRA_ARGS into an array, so we first convert the command-line array to a string, and then afterwards simply append the extra args.
Several of these tests fail to pass TEST_PHP_EXTRA_ARGS to the PHP binary they execute. This can lead to spurious failures when, for example, the system's INI file is incompatible with the just-built CLI php: ---- EXPECTED OUTPUT int(111) ---- ACTUAL OUTPUT Failed loading /usr/lib64/php8.2/lib64/opcache.so: /usr/lib64/php8.2/lib64/opcache.so: undefined symbol: _emalloc_32 int(111) ---- FAILED This commit adds TEST_PHP_EXTRA_ARGS to the "php" invocations that are missing them, allowing the user to run "run-tests.php -n" to work around the problem.
In some cases, on Windows, we pass -dextension=mysqli to the test runner, but omit the extension_dir. This works fine so long as that extension_dir can be obtained from php.ini. However, we have at least one test that loads some other (or no) php.ini file; when that happens, the mysqli extension cannot be found. To solve that problem, we now also specify an extension_dir whenever we specify an extension to load.
Two of our proc_open() tests pass code to PHP via the shell, leading to three levels of quoting, one of which makes cmd.exe unhappy on Windows. To avoid the issue, we use a temporary file instead, and pass only the (at most, once-quoted) name of the file to PHP.
dde18ce
to
3cd30ff
Compare
I didn't realize this branch had a conflict. A line adjacent to something that I changed was changed. Force-pushed a fix to |
Any chance to get this merged? Gentoo users run the test suite when PHP is installed, and they can easily switch between debug and non-debug builds by passing a flag to the package manager. I'm having to delete these tests each time to avoid the failures in that case. |
If I test a debug build while I have a non-debug PHP installed on the system, I get a bunch of test failures that can all be traced back to,
The non-debug
opcache.so
is trying to load from the system's INI file.Of course, I'm running the tests with
sapi/cli/php -n ./run-tests.php -n
, but the-n
is not always passed to sub-invocations of PHP inside the test cases. This PR fixes most of them by passingTEST_PHP_EXTRA_ARGS
to those invocations, but a few (described in the commit message) were much simpler to fix with only an-n
.