Preloading shutdown calls request shutdown which will deactivate the
virtual cwd state. However, further startup code still assumes the state
that was set by virtual_cwd_startup(). So we need to reactivate it
manually.
Creating a test was a bit difficult because the INI setting I wanted to
test this with is overridden by the test runner apparently.
To reproduce the issue, create an empty file test.php and execute this
in a ZTS build:
`php -d opcache.preload=./ext/opcache/tests/preload_class_alias_2.inc -d "error_log=" -d "allow_url_include=1" test.php`
Closes GH-18117.
This solely affects the builtin enum functions currently.
Given that these are stored in SHM, we cannot simply hardwire a pointer into the internal function runtime cache on NTS too, but have to use a MAP_PTR (like on ZTS).
Now, by design, the runtime cache of internal functions no longer is reset between requests, hence we need to store them explicitly as static runtime cache.
On NTS builds we cannot trivially move the pointers into CG(internal_run_time_cache) as they're directly stored on the individual functions (on ZTS we could simply iterate the static map_ptrs).
Hence, we have the choice between having opcache managing the internal run_time_cache for its preloaded functions itself or realloc CG(internal_run_time_cache) and iterate through all functions to assign the new address. We choose the latter for simplicity and initial speed.
As explained by Snape3058: On 64-bit machines, we typically have 7 bytes
of padding between the zend_string.val[0] char and the following char[].
This means that zend_string.val[1-7] write to and read from the struct
padding, which is a bad idea.
Allocate the given string separately instead.
Fixes GH-17564
Closes GH-17576
This bug happens because of a nested `SHM_UNPROTECT()` sequence.
In particular:
```
unprotect memory at ext/opcache/ZendAccelerator.c:2127
protect memory at ext/opcache/ZendAccelerator.c:2160
unprotect memory at ext/opcache/ZendAccelerator.c:2164
unprotect memory at ext/opcache/jit/zend_jit_trace.c:7464
^^^ Nested
protect memory at ext/opcache/jit/zend_jit_trace.c:7591
^^^ Problem is here: it should not protect again due to the nested unprotect
protect memory at ext/opcache/ZendAccelerator.c:2191
^^^ This one should actually protect, not the previous one
```
The reason this nesting happen is because:
1. We try to include the script, this eventually calls `cache_script_in_shared_memory`
2. `zend_optimize_script` will eventually run SCCP as part of the DFA pass.
3. SCCP will try to replace constants, but can also run destructors when a partial array is destructed here:
4e9cde758e/Zend/Optimizer/sccp.c (L2387-L2389)
In this case, this destruction invokes the GC which invokes the tracing JIT,
leading to the nested unprotects.
This patch disables the GC to prevent invoking user code, as user code
is not supposed to run during the optimizer pipeline.
Closes GH-17249.
Co-authored-by: Dmitry Stogov <dmitry@zend.com>
There doesn't seem to be a thread post-startup hook that runs after
zend_startup_cb() that could be used for this
this fix is similar to accel_startup_ok() as seen here: fc1db70f10/ext/opcache/ZendAccelerator.c (L2631-L2634)
Closes GH-16853.
This happens because on ZTS we execute `executor_globals_ctor` which reset the
`freelist` and `p5s` pointers, while on NTS we don't.
On NTS we can reuse the caches but on ZTS we can't, the easiest fix is
to call `zend_shutdown_strtod` when preloading is shut down.
This regressed in GH-13974 and therefore only exists in PHP 8.4 and
higher.
Closes GH-16602.
There are two related issues, each tested.
First problem:
What happens is that on the CLI SAPI we have a per-request pcre cache,
and on there the request shutdown for the pcre module happens prior to
the remaining live object destruction. So when the SPL object wants to
clean up the regular expression object it gets a use-after-free.
Second problem:
Very similarly, the non-persistent resources are destroyed after request
shutdown, so on the CLI SAPI the pcre request cache is already gone, but
if a userspace stream references a regex in the pcre cache, this breaks.
Two things that come immediately to mind:
- We could fix it by no longer treating the CLI SAPI special and just use
the same lifecycle as the module. This simplifies the pcre module code
a bit too. I wonder why we even have the separation in the first place.
The downside here is that we're using more the system allocator
than Zend's allocator for cache entries.
- We could modify the shutdown code to not remove regular expressions
with a refcount>0 and modify php_pcre_pce_decref code such that it
becomes php_pcre_pce_decref's job to clean up when the refcount
becomes 0 during shutdown. However, this gets nasty quickly.
I chose the first solution here as it should be reliable and simple.
Closes GH-15064.
The crash happens because the zend_persist.c code tries to JIT the hook's
op_array while the JIT buffer memory is still protected. This happens in
`zend_persist_property_info` called via `zend_persist_class_entry`
through the inheritance cache.
We shouldn't JIT the property hook code when persisting property info
for the inheritance cache.
This is a simple workaround by temporarily disabling the JIT so that the
property hook code is not JITted when persisting the property info.
An alternative solution would be to move the JITting of the property
hooks to a different place in zend_persist.c by doing an additional pass
over the classes.
Closes GH-15819.
* Mark many functions as static
Multiple functions are missing the static qualifier.
* remove unused struct sigactions
struct sigaction act, old_term, old_quit, old_int;
all unused.
* optimizer: minXOR and maxXOR are unused
Compress interned string table offsets and increase maximum supported buffer size
The interned string buffer is organized as a header + a hash table + a
zend_string arena. Hash slots point to the arena, but are represented as 32bit
offsets from the buffer, which limits the maximum buffer size to about 4GiB.
However zend_strings are 8-byte aligned in the buffer, so we can compress the
3 lower bits. This allows to increase the maximum supported interned string
buffer size from 4095 MiB to 32767 MiB.
The former implementation of huge pages for PHP code segments may
fail to map in certain scenarios. For instance, if the initial
'r-x-' segment is not PHP, it will result in a failure to map into
huge pages. Consequently, the optimization for huge pages with PHP
code will no longer be effective.
This patch improves the implementation by accurately matching all
'r-x-' segments until it locates the PHP code segment. Subsequently,
it performs the necessary huge page mapping.
Reviewed-by: chen-hu-97 <hu1.chen@intel.com>
Signed-off-by: PeterYang12 <yuhan.yang@intel.com>
After preloading has executed, the executor globals for class_table and
function_table are still referring to the values during preloading.
If no request happens after that then these values will remain dangling
pointers. If then the -v option on CLI or -h option (and possibly
others) on CGI is provided, there is a double free.
Fix it by nulling the pointers explicitly after preloading has finished
to fix it for all SAPIs.
Closes GH-12311.
Fix for #76857 introduced slight perf regression so this is an attempt
to fix it. The idea is to re-use stream path check from ZendAccelerator
that should be quicker than strstr.
Signed-off-by: Jakub Zelenka <bukka@php.net>
This feature has been broken at least since the tracing JIT and inheritance
cache have been introduced. The attempted fix (GH-10798) was too complex. We
have thus decided to remove this feature for now.
Closes GH-11832
There are a couple of oddities.
1) The interned strings buffer comprises the whole hashtable
datastructure.
Therefore, it seems that the interned strings buffer size is the size of
only said table. However, in the current code it also includes the size
of the zend_accel_shared_globals.
2) ZCSG(interned_strings).end is computed starting from the accelerator
globals struct itself. I would expect it to start from the part where
the interned strings table starts.
3) When computing the used size, it is done using
ZCSG(interned_strings).end - ZCSG(interned_strings).start. However,
this does not include the uin32_t slots array because
ZCSG(interned_strings).start pointers after that array.
This patch corrrects these 3 points.
Closes GH-11717.
