| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Test with 4.8 is OK
With 4.4: error: #pragma GCC diagnostic not allowed inside functions
|
| |
|
|
|
|
|
| |
The state returned by `sodium_crypto_generichash_init()` has to be
regarded as opaque byte string; neither its size nor its exact
structure are fixed, and actually vary for diffent libsodium versions.
Therefore we drop the test altogether.
|
| | |
|
| |
|
|
|
|
| |
sodium_crypto_generichash_init()
Backport jedisct1/libsodium.php@28d13bf437cb969a0583031fc7ac54c5a8dc8116.
|
| |
|
|
|
|
|
| |
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
c88ffa9a5673cb3141660626ba1921671f0b84d6
|
| | |
|
| |
|
|
| |
On PHP 7.2 our minimum ICU version is 4.0, not 40.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
We have to bail out, if an invalid resource is given. For consistency
with the other `zend_fetch_resource(2)` calls, we return `FALSE`.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Backported from a1a8d144854acb1c891cf0c21abb0f612b1d8de7
https://www.php.net/manual/en/function.passthru.php#refsect1-function.passthru-returnvalues
`passthru()` is false with invalid args
`passthru('command')` is null.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| | |
* PHP-7.1:
Fix #75457: heap-use-after-free in php7.0.25
|
| | |
| |
| |
| | |
Backport <https://vcs.pcre.org/pcre?view=revision&revision=1638>.
|
| |\ \
| |/
| |
| |
| |
| | |
* PHP-7.1:
Fix CVE-2019-13224: don't allow different encodings for onig_new_deluxe()
set version for release
|
| | |
| |
| |
| | |
Backport from https://github.com/kkos/oniguruma/commit/0f7f61ed1b7b697e283e37bd2d731d0bd57adb55
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
_server_host
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 should only be included in the generator GC buffer, if it
will be released on destruction.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
As the properties array can also be a GC root, it might have
already been destroyed.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 bf242d58e77d50d4d8fdaaaca7ede686ec4467c0)
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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] <https://github.com/MariaDB/server/commit/c50ee6c23dbeb090963580754bec2f0a96ac0557#diff-5b45fa673c88c06a9651c7906364f592>
|
| | | |
|
| | | |
|
| |\ \
| |/
| |
| |
| |
| |
| |
| | |
* PHP-7.1:
Fix #77919: Potential UAF in Phar RSHUTDOWN
Update NEWS
Fix bug #78256 (heap-buffer-overflow on exif_process_user_comment)
Fix bug #78222 (heap-buffer-overflow on exif_scan_thumbnail)
|
| | |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Similar to what fread() does, truncate the stream_get_contents()
result if the original buffer was way too large.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
