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>
This is for LDAP_OPT_X_TLS_PROTOCOL_MIN and LDAP_OPT_X_TLS_PROTOCOL_MAX
It also adds a test that uses LDAPCONF with TLS max version lower than
the minimum TLS server version so it should always fail. However it
does not fial for the second case without this change which confirms
that the change works as expected.
Closes GH-18676
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.
