When stored procedures are called, the "final result set is a status
result that includes no result set". Calling `::nextRowset()` on the
actual last result set should return FALSE, since there is actually no
further result set to be processed.
It can return false if the resource type is wrong.
```
php > var_export(hash_update_stream(hash_init('md5'),
imagecreate(1,1)));
Warning: hash_update_stream(): supplied resource is not a valid stream
resource in php shell code on line 1
false
```
The return types were initially added in
c88ffa9a56
fcgi_accept_request function is supposed to call a FastCGI implementation's
on_accept hook when entering an "accepting" stage (that is right before
calling "accept"). This hook implementation (fpm_request_accepting) updates
a worker state to an "accepting" state which is effectively an "Idle" state,
and updates counters on the scoreboard of the corresponding pool (idle++,
active--).
But this is not done when listening for client connections on a named pipe on
Windows platform. In that case a combination of
ConnectNamedPipe/WaitForSingleObject is used (to be able to catch in_shutdown
as far as I understand), but it is nonetheless functionally equivalent to
"accept" call. Also by not calling on_hook neither a worker's state is updated
to "accepting" state nor scoreboard counters are updated.
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.
This can also return an array. See
https://www.php.net/manual/en/function.time-nanosleep.php#refsect1-function.time-nanosleep-returnvalues
> If the delay was interrupted by a signal, an associative array will be
returned with the components:
>
> - seconds - number of seconds remaining in the delay
> - nanoseconds - number of nanoseconds remaining in the delay
Sending a SIGUSR1 to the below program would trigger this behavior.
```
pcntl_signal(\SIGUSR1, function ($signo, $signinfo) {
echo "Handling a signal $signo\n";
});
echo "Sleeping for 100 seconds\n";
var_export(time_nanosleep(100, 0));
```
The incomplete signature existed since c88ffa9a5.
No phpt tests existed for time_nanosleep returning an array
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.
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.
The fix for bug #78241 assumed that `time_t` would always be 64bit, but
actually is 32bit for x86. We therefore enforce 64bit arithmetic to
avoid wrapping.
(cherry picked from commit bf242d58e7)
As of MariaDB 10.0.2, the server reports a fake version number as work-
around for replication issues[1]. We apply the same "fix" as in the
MariaDB client to cater to this.
[1] <c50ee6c23d (diff-5b45fa673c88c06a9651c7906364f592)>
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.
1. falls in an infinite loop because PHP engine's inconsistent state, now override the ITIMER_PROF to 0.1 second, clean shutdown must finish before that.
2. generate too much error log, we completely disable "error_reporting" before calling php_request_shutdown().
