If there's a try-finally where the try_op starts on a basic block with a
single JMP, and the JMP optimization causes that basic block to become
unreachable, then we update try_op.
In this case, there is no catch_op, so try_op is erroneously set to 0,
we should instead set it to `b->start`.
Closes GH-18110.
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 is a bit of a theoretical issue, but the maximum string length is
actually ZSTR_MAX_LEN instead of SIZE_MAX. The resulting check is a bit
slower but should still be relatively cheap.
Closes GH-18049.
When a guard check is created for a variable to check if it's a packed array,
it is possible that there was no prior type check for that variable.
This happens in the global scope for example when the variable aliases.
In the test, this causes a dereference of address 8 because the integer
element in `$a` is interpreted as an array address.
This patch adds a check to see if the guard is handled.
If we were not able to determine or guard the type then we also cannot know the array is packed.
Closes GH-17584.
This test has two classes that use the same trait. In function JIT mode
the same cache slot will be used. This causes problems because it is
primed for the first class and then reused for the second class,
resulting in an incorrect type check failure.
The current check for a megamorphic trait call requires current_frame to
not be NULL, but this is only set in tracing mode and not in function
mode.
This patch corrects the check.
Closes GH-17660.
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>
op1 of ZEND_MATCH_ERROR, which refers to the match expression, is not freed by
MATCH_ERROR itself. Instead, it is freed by ZEND_HANDLE_EXCEPTION. For normal
control flow, a FREE is placed at the end of the match expression.
Since FREE may appear after MATCH_ERROR in the opcode sequence, we need to
correctly handle op1 of MATCH_ERROR as alive.
Fixes GH-17106
Closes GH-17108
The `jit_prof_threshold` is a float, supposed to be in range [0, 1],
and usually very small (the default is 0.005). Reporting it as int
is meaningless.
Closes GH-17077.
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.
When returning an UNDEF value, it actually becomes NULL.
The following code took this into account:
28344e0445/ext/opcache/jit/zend_jit_trace.c (L2196-L2199)
But the stack does not update the type to NULL, causing a mismatch.
Closes GH-16784.
Co-authored-by: Dmitry Stogov <dmitry@zend.com>
