* fix segfault in `ZEND_BIND_STATIC`
In case a `ZEND_BIND_STATIC` is being executed, while the current chunk is full,
the `zend_array_dup()` call will trigger a OOM in ZendMM which will crash, as
the opline might be a dangling pointer.
* add missing test
* `assert()`ing seems easier than trying to make the compiler to not optimize
* moved from function call to INI setting, so we can use this in other places as well
* make `assert()` work no NDEBUG builds
* document magic number
* fix segfault in `ZEND_FUNC_GET_ARGS`
In case a `ZEND_FUNC_GET_ARGS` is being executed, while the current chunk is
full, the `zend_new_array()` call will trigger a OOM in ZendMM which will crash,
as the opline might be a dangling pointer.
---------
Co-authored-by: Florian Engelhardt <florian@engelhardt.tc>
php_strip_url_passwd modifies url in-place. We cannot assume from
php_message_handler_for_zend that data is a temporary, modifiable string.
Fixes oss-fuzz #64209
Closes GH-12733
Right-shifting a negative number is unspecified (i.e.
implementation-defined) behaviour [1]. If we take a look at the
generated assembly [2], we see that the wrong value is computed.
Fix it by using Z_UL instead of Z_L.
While we're at it, just change every occurrence of this pattern to use
Z_UL instead of casting.
[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf §6.5.7.5
[2] https://godbolt.org/z/4Y1qKKjsh
Closes GH-12613.
When redeclaring an overridden static property with a trait we're removing the
property from the class. However, because the property itself does not belong to
the class we must not free its associated data.
This issue is exposed by 9a250cc9d6 in PHP 8.3+ because duplicate static
properties in traits are no longer skipped, but redeclared.
Fixes GH-12468
This test triggers narrowing for two ops: first ZEND_ADD_ARRAY_ELEMENT,
and then ZEND_ASSIGN.
The type inference happens in the following order:
1) The ZEND_ADD_ARRAY_ELEMENT infers type 0x40e04080 (packed flag is set),
arr_type=0 at this point because it hasn't been set by ZEND_INIT_ARRAY yet.
2) The ZEND_INIT_ARRAY infers type 0x40804080
3) The ZEND_ADD_ARRAY_ELEMENT infers type 0x40e04080, arr_type=0x40804080,
which does not have the packed flag set while the existing result of
ZEND_ADD_ARRAY_ELEMENT has the packed flag set.
This seems to occur because of the phi node introduced by the while
loop. If I remove the loop the problem goes away.
As Arnaud noted, this seems to be caused by a too wide type inference
for arr_type==0. We should keep the invariant that if x>=y then
key_type(x) >= key_type(y).
If we write the possible results down in a table we get:
```
arr_type resulting key type
--------------- --------------------------------------------------------------------------
HASH_ONLY -> MAY_BE_ARRAY_NUMERIC_HASH
PACKED_ONLY -> MAY_BE_ARRAY_NUMERIC_HASH | MAY_BE_ARRAY_PACKED (== MAY_BE_ARRAY_KEY_LONG)
HASH || PACKED -> MAY_BE_ARRAY_NUMERIC_HASH | MAY_BE_ARRAY_PACKED (== MAY_BE_ARRAY_KEY_LONG)
0 -> MAY_BE_ARRAY_NUMERIC_HASH | MAY_BE_ARRAY_PACKED (== MAY_BE_ARRAY_KEY_LONG)
```
As we can see, `HASH_ONLY > 0` but
`MAY_BE_ARRAY_NUMERIC_HASH < MAY_BE_ARRAY_NUMERIC_HASH | MAY_BE_ARRAY_PACKED`,
which violates the invariant.
Instead if we modify the zero case to have MAY_BE_ARRAY_NUMERIC_HASH instead,
we get the following table which satisfies the invariant.
```
arr_type resulting key type
--------------- --------------------------------------------------------------------------
HASH_ONLY -> MAY_BE_ARRAY_NUMERIC_HASH
PACKED_ONLY -> MAY_BE_ARRAY_NUMERIC_HASH | MAY_BE_ARRAY_PACKED (== MAY_BE_ARRAY_KEY_LONG)
HASH || PACKED -> MAY_BE_ARRAY_NUMERIC_HASH | MAY_BE_ARRAY_PACKED (== MAY_BE_ARRAY_KEY_LONG)
0 -> MAY_BE_ARRAY_NUMERIC_HASH
```
Broke in 1ffbb73.
Closes GH-10294.
When declaring the same static property with a doc block in a class and in a trait,
the doc block of the property in the class is leaked. While at it, possibly fix doc
comment for internal classes.
Close GH-12238
These tests intermittently crash asan. It might be due to some function invoking
dl(), which is known to crash lsan. It might also be something else, the version
of asan shipped with ubuntu 22.04 is flaky.
Addref to relevant fields before allocating any memory. Also only set/remove the
ZEND_ACC_HEAP_RT_CACHE flag after allocating memory.
Fixes GH-12073
Closes GH-12074
Evaluating constants at comptime can result in arrays that contain objects. This
is problematic for printing the default value of constant ASTs containing
objects, because we don't actually know what the constructor arguments were.
Avoid this by not propagating array constants.
Fixes GH-11937
Closes GH-11947
Normally, PHP evaluates all expressions in offsets (property or array), as well
as the right hand side of assignments before actually fetching the offsets. This
is well explained in this blog post.
https://www.npopov.com/2017/04/14/PHP-7-Virtual-machine.html#writes-and-memory-safety
For ??= we have a bit of a problem in that the rhs must only be evaluated if the
lhs is null or undefined. Thus, we have to first compile the lhs with BP_VAR_IS,
conditionally run the rhs and then re-fetch the lhs with BP_VAR_W to to make
sure the offsets are valid if they have been invalidated.
However, we don't want to just re-evaluate the entire lhs because it may contain
side-effects, as in $array[$x++] ??= 42;. In this case, we don't want to
re-evaluate $x++ because it would result in writing to a different offset than
was previously tested. The same goes for function calls, like
$array[foo()] ??= 42;, where the second call to foo() might result in a
different value. PHP behaves correctly in these cases. This is implemented by
memoizing sub-expressions in the lhs of ??= and reusing them when compiling the
lhs for the second time. This is done for any expression that isn't a variable,
i.e. anything that can (potentially) be written to.
Unfortunately, this also means that function calls are considered writable due
to their return-by-reference semantics, and will thus not be memoized. The
expression foo()['bar'] ??= 42; will invoke foo() twice. Even worse,
foo(bar()) ??= 42; will call both foo() and bar() twice, but
foo(bar() + 1) ??= 42; will only call foo() twice. This is likely not by design,
and was just overlooked in the implementation. The RFC does not specify how
function calls in the lhs of the coalesce assignment behaves. This should
probably be improved in the future.
Now, the problem this commit actually fixes is that ??= may memoize expressions
inside assert() function calls that may not actually execute. This is not only
an issue when using the VAR in the second expression (which would usually also
be skipped) but also when freeing the VAR. For this reason, it is not safe to
memoize assert() sub-expressions.
There are two possible solutions:
1. Don't memoize any sub-expressions of assert(), meaning they will execute
twice.
2. Throw a compile error.
Option 2 is not quite simple, because we can't disallow all memoization inside
assert(), as that would break assertions like assert($array[foo()] ??= 'bar');.
Code like this is highly unlikely (and dubious) but possible. In this case, we
would need to make sure that a memoized value could not be used across the
assert boundary it was created in. The complexity for this is not worthwhile. So
we opt for option 1 and disable memoization immediately inside assert().
Fixes GH-11580
Closes GH-11581
