The properties HT may be a GC root itself, so we need to remove it.
I'm not sure this issue actually applies to PHP 7.2, but committing
it there to be safe. As seen from the test case, the handling here
is rather buggy on 7.2.
Due to overflows in the memory limit checks, we were missing cases
where the allocation size was close to the address space size, and
caused an OOM condition rather than a memory limit error.
As of Windows 1903, when the OneDrive on-demand feature is enabled, the
OneDrive folder is reported as reparse point by `FindFirstFile()`, but
trying to get information about the reparse point using
`DeviceIoControl()` fails with `ERROR_NOT_A_REPARSE_POINT`. We work
around this problem by falling back to `GetFileInformationByHandle()`
if that happens, but only if the reparse point is reported as cloud
reparse point, and only if PHP is running on Windows 1903 or later.
The patch has been developed in collaboration with ab@php.net.
We should keep an eye on the somewhat quirky OneDrive behavior, since
it might change again in a future Windows release.
In PHP 7.3 shadow properties are no longer duplicated. Make sure we
only release them if the property was defined on the parent class,
which means that it changed from private->shadow, which is where
duplication does happen.
This is likely going to end up interned lateron at some point
when the new_name is referenced somewhere. However, it may be
that there are some uses that do not get interned before that.
In this case we will intern a string that already have zval
users, without updating the refcounted flag on those zvals.
In particular this can happen with something like [Foo::class],
where Foo is an imported symbol. The string it resolves to won't
get interned right away, but may be interned later.
use Foo as Bar;
$x = [Bar::class];
var_dump(Bar::X);
debug_zval_dump($x); // Will show negative refcount
class Foo {
const X = 1;
}
However, this doesn't really fix the root cause, there are probably
other situations where something similar can occur.
There are a few parts here:
* opcache should not be blocking signals while invoking compile_file,
otherwise signals may remain blocked on a compile error. While at
it, also protect SHM memory during compile_file.
* We should deactivate Zend signals at the end of the request, to make
sure that we gracefully recover from a missing unblock and signals
don't remain blocked forever.
* We don't use a critical section in deactivation, because it should
not be necessary. Additionally we want to clean up the signal queue,
if it is non-empty.
* Enable SIGG(check) in debug builds so we notice issues in the future.
When cleaning nops in the dfa pass, we were always keeping the
smart branch inhibiting nop that occurs directly before the jump
instruction. However, as we skip unreachable blocks entirely, it
may happen that we need to keep a nop that occurs further back,
prior to the unreachable blocks. Account for that case now.
We should really do something about the smart branch situation,
this is very fragile...
If we perform a class fetch that is not marked as exception safe,
convert exceptions thrown by autoloaders into a fatal error.
Ideally fetching the interfaces would be exception safe, but as it
isn't right now, we must abort at this point.
