When opcache is enabled, error handling is altered in the following ways:
* Errors emitted during compilation bypass the user-defined error handler
* Exceptions emitted during class linking are turned into fatal errors
Changes here make the behavior consistent regardless of opcache being enabled or
not:
* Errors emitted during compilation and class linking are always delayed and
handled after compilation or class linking. During handling, user-defined
error handlers are not bypassed. Fatal errors emitted during compilation or
class linking cause any delayed errors to be handled immediately (without
calling user-defined error handlers, as it would be unsafe).
* Exceptions thrown by user-defined error handlers when handling class linking
error are not promoted to fatal errors anymore and do not prevent linking.
Fixes GH-17422.
Closes GH-18541.
Closes GH-17627.
Co-authored-by: Tim Düsterhus <tim@bastelstu.be>
This removes the --enable-opcache/--disable-opcache configure switch. OPcache
is now always builtin. The default value of opcache.enable and
opcache.enable_cli is unchanged.
RFC: https://wiki.php.net/rfc/make_opcache_required
Closes GH-18961.
Co-authored-by: Tim Düsterhus <tim@tideways-gmbh.com>
The search order for DLLs on Windows is (simplified):
* the application folder
* the system folder
* all folders in the `PATH`
(The full details are documented on Microsoft Learn[1].)
As is, we're adding `deps\bin` to the `PATH` when running the tests,
but any DLLs in the system folder take precedence, so these would be
used instead of our intended dependencies. To mitigate that, we copy
over all DLLs from `deps\bin` to our application folder (i.e. where
php.exe, php-cgi.exe and phpdbg.exe are placed).
Since we're doing this, there is no more need to attempt to remove the
OpenSSL DLLs in the system folder (what seems to be a bad idea anyway).
[1] <https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order>
Closes GH-17805.
* Fix GH-17658: COMPersistHelper::LoadFromStream() can segfault
The actual fix is trivial, but to be able to test the behavior we have
to introduce an own COM object, since existing persistable objects
likely implement `IPersistInit`, not only `IPersist`. We also want to
avoid further test dependencies on possibly unavailable objects, such
as `Word.Application`.
To this purposes, we add a small COM in-process server, which may be
extended for other testing purposes. We keep it simple by implementing
it in C++, but without using any more sophisticated frameworks like ATL.
This component needs to be built explicitly (`nmake comtest.dll`), and
also needs to be explicitly registered (`nmake register_comtest`).
When no longer needed, it is possible to unregister the component
(`nmake unregister_comtest`).
For some reason the stack reserve of php.exe and php-cgi.exe is very
large on Windows (64MB)[1]. While this might not be bad for production
purposes, it causes stack_limit_014.phpt to be unbearably slow; the
test may easily run for a minute, and due to a recent `stream_select()`
improvement[2], that can cause a timeout, what triggers the test to be
run again. So this single test case may run for two minutes, and still
might fail (happened a couple of times).
Instead of skipping the test in CI, we reduce the stack reserve to 8MB,
what improves the performance of this test case (and maybe others), and
should still be good enough for CI.
[1] <54906c760f>
[2] <b614b4a69a>
It seems reasonable to have an ASan job on Windows, especially to be
able to check Windows specific code. Since the tests may take about
70 minutes, it doesn't make sense to add these for pushes, but for a
nightly job that should be okay.
Closes GH-17087.
Since windows.php.net is in the progress to be migrated to
downloads.php.net anyway, we may as well fetch the dictionary from the
new site right away.
Closes GH-16310.
php_pdo_firebird.dll depends on fbclient.dll, which is shipped with the
server. However, a 64bit Firebird server ships a 64bit fbclient.dll,
which is not compatible with a 32bit php_pdo_firebird.dll.
Closes GH-16223.
The bless_tests.patch had been introduced via PR #7204, but is no
longer available due to PR #11566. Since apparently the patch is not
that helpful, we remove the code which generates it.
Prior to running the tests, the test runner checks for all generally
available extensions; it does this by scanning the `extension_dir` for
files matching the typical extension pattern, but verifies that the
file is actually a PHP extension by calling `dl()`. However, `dl()`
has known issues[1]. On Windows CI we always get an ugly "zend_mm_heap
corrupted" message, and we even can't `dl()` ext/mysql when OPcache is
enabled[2]. So we better avoid the double-check with `dl()`, which is
unlikely to be necessary anyway.
[1] <https://github.com/php/php-src/issues/9196>
[2] <https://github.com/php/php-src/issues/8508>
This test queries `extOutput` for the first line of output of the
command which was executed when snmpd started (`HexTest` in snmpd.conf).
Since there is no `/bin/sh` on Windows, no command would be run, and as
such we received an empty string. We fix that by dynamically adjusting
snmpd.conf to run a JScript which has the same output as bigtest.
We also make the test diff more helpful in case of failures, where so
far we only would have known that the output had a different message
digest.
That was broken when CI was moved to GH, since `APPVEYOR_BUILD_FOLDER`
is no longer set; instead we use `GITHUB_WORKSPACE` which has the same
meaning.
Closes GH-15896.
This value would be so high, occupying 88MB of shm on my machine and effectively
disabling the JIT in some cases.
Co-authored-by: Daniil Gentili <daniil@daniil.it>
The path to mysql.exe changed. Fortunately, chocolately puts the folder
containing the exe in the PATH environment variable, so we don't even
need to provide an absolute path.
