Make sure that fpm_event_add calls inside a timer callback work by
unregistering the event from the queue before invoking its callback.
The read timeout in tester.inc is increased because the added test
needs two seconds (one for SIGTERM, one for SIGKILL) until the
reload succeeds, so we should wait longer than that for a response.
Argument unpacking may need to create references inside the array
that is being unpacked. However, it currently can only do this
if a plain variable is unpacked, not for any nested accesses,
because the value is fetched for read. Resolve this by fetching
the operands for RW.
We have to properly clean up in case phar_flush() is failing.
We also make the expectation of the respective test case less liberal
to avoid missing such bugs in the future.
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.
The smart branch logic assumed b->start refers to the old offsets,
while b->start was already adjusted to the new offsets at this
point. Delay the change until later.
When performing a constant visibility check during compilation we
might be dealing with unlinked classes and as such should account
for the possibility of unresolved parents.
Even if we know the file size, we still need to read in a loop in
case the read call returns an incomplete result.
This was less of an issue previously because we did not use the
"one large read" approach for non-plain stream wrappers.
These two files have been: "UTF-8 Unicode (with BOM) text".
By applying `dos2unix` on these files the BOM has been removed.
I checked the whole source code with dos2unix:
These were the only two text files affected.
