When the user does not fully consume the data stream, but instead opens
a new one, a memory leak occurs. Moreover, the state is invalid: when
more commands arrive they'll be handled out-of-sync because the state of
the client does not match what the server is doing.
This leads to all sorts of weirdness, for example:
Warning: ftp_nb_fget(): OK.
Fix it by gracefully closing the old data stream when a new data stream
is started.
Closes GH-11606.
The error handling is replaced using zend_replace_error_handling(), but
when SQLITE3_CHECK_INITIALIZED() returns early, the old error handling
isn't restored.
In the past, SQLITE3_CHECK_INITIALIZED() threw a warning when the check
failed. This was replaced a few years ago with an error exception. So we
can fix the bug by just removing the replacing error handling as it
accomplishes nothing anymore.
Closes GH-11607.
* ext/gd/tests/bug45799.phpt: tweak to work with external gd.
The expected output from this test contains an extra newline with
gd-2.3.3 from the system (Gentoo). Adding a whitespace wildcard takes
care of it, and the test still passes with the bundled version of gd.
* ext/gd/tests: external gd-2.3.3 compatibility.
Support for the legacy "gd" image format was removed from gd-2.3.3
upstream:
https://github.com/libgd/libgd/blob/master/CHANGELOG.md#233---2021-09-12
Several tests for the gd extension utilize that format, and naturally
fail when gd-2.3.3 from the system is used. This commit skips those
tests when the version of gd is at least 2.3.3.
* ext/gd/tests/bug73159.phpt: skip with external gd >= 2.3.3
This test uses the imagegd2() function to check that
https://github.com/libgd/libgd/issues/289
is fixed. When an external gd without support for the "gd" format is
used, no error is thrown, but a nonsense result is printed: this is
normal. The corresponding upstream test is disabled in that situation;
it's not expected to work.
This commit skips the corresponding PHP test under the same
circumstances to fix a test failure with external gd >= 2.3.3.
* ext/gd/tests/bug73155.phpt: skip with external gd >= 2.3.3
This test uses the imagegd2() function to check that
https://github.com/libgd/libgd/issues/309
is fixed. When an external gd without support for the "gd" format is
used, no error is thrown, but a nonsense result is printed: this is
normal. The corresponding upstream test is disabled in that situation;
it's not expected to work.
This commit skips the corresponding PHP test under the same
circumstances to fix a test failure with external gd >= 2.3.3.
* ext/gd/tests/bug73157.phpt: skip with external gd >= 2.3.3
This test ensures that the third (chunk_size) parameter to imagegd2()
is respected when a fourth parameter is also given. However, when an
external gd without support for the "gd" format is used, the call to
imagegd2() does not really work at all. It doesn't fail, but it
produces an "image" with a nonsense chunk size.
To avoid failures when an external gd >= 2.3.3 is used, we skip the
test entirely in that case.
* ext/gd/tests/bug77973.phpt: accept lowercase "Invalid"
This test fails with an external gd because the test expects "Invalid"
where upstream gd says "invalid". This commit tweaks the expected
output to accept an arbitrary character in the i/I position.
* ext/gd/tests/bug39780_extern.phpt: update for external gd-2.3.3.
Since there are no CI runs with external gd, I can only assume that
this test has fallen out-of-date due to changes in PHP itself. I've
tweaked the expected output (only slightly) so that the test passes
with both gd-2.3.2 and gd-2.3.3.
* ext/gd/tests/bug66356.phpt: update expected output for external gd.
Newer (external) versions of GD start their error messages with
lowercase characters, whereas this test is expecting them in
uppercase. A single-character wildcard now supports both formats.
* ext/gd/tests/imagegd_truecolor.phpt: skip with external gd >= 2.3.3.
This test uses the imagegd() function, but the "gd" format has been
disabled by default in upstream gd-2.3.3. We still get some kind of
image data back from the call to imagegd(), but its "signature",
"truecolor", and "size" no longer match the expected values. This
commit skips the test when an external gd >= 2.3.3 is used.
* ext/gd/tests/createfromwbmp2_extern.phpt: update for external gd-2.3.3.
* ext/gd/tests/libgd00086_extern.phpt: update for external gd-2.3.3.
Since there are no CI runs with external gd, I can only assume that
this test has fallen out-of-date due to changes in PHP itself. I've
tweaked the expected output (only slightly) so that the test passes
with both gd-2.3.2 and gd-2.3.3.
* ext/gd/tests/bug77272.phpt: update expected output for external gd.
Newer (external) versions of GD start their error messages with
lowercase characters, whereas this test is expecting them in
uppercase. A single-character wildcard now supports both formats.
* ext/gd/tests/bug77479.phpt: update for newer external gd.
This test fails with gd-2.3.3 (at least) due to minor capitalization
and whitespace issues. We add some wildcards to account for the
difference.
Closes GH-11257.
Closes GH-11262.
Closes GH-11264.
Closes GH-11280.
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
Previously, if an object had RC1 it would never be recorded in
php_serialize_data.ht because it was assumed that it could not be encountered
again. This assumption is incorrect though as the object itself may be saved
inside an array with RCn. This results in a new instance of the object, instead
of a second reference to the same object.
This is solved by tracking these objects in php_serialize_data.ht. To retain
performance, track if the current object resides in a potentially nested RCn
array. If not, and if the object is RC1 itself it may be omitted from
php_serialize_data.ht.
Additionally, we may treat the array root itself as RC1 because it may not
appear in the object graph again without recursion. Recursive arrays are still
somewhat broken even with this change, as the tracking of the array only happens
when the reference is encountered, thus resulting in a -> a' -> a' for a self
recursive array a -> a. Recursive arrays have limited support in serialize
anyway, so we ignore this case for now.
Co-authored-by: Dmitry Stogov <dmitry@zend.com>
Co-authored-by: Martin Hoch <martin@littlerobot.de>
Closes GH-11349
Closes GH-11305
Linux, and maybe other unixes, may merge multiple standard signals into
a single one. This causes issues when keeping track of process IDs.
Solve this by manually checking which children are dead using waitpid().
Test case is based on taka-oyama's test code.
Closes GH-11509.
When writing the output in the CLI is interrupted by a signal, the
writing will fail in sapi_cli_single_write(), causing an exit later in
sapi_cli_ub_write(). This was the other part of the issue in GH-11498.
The solution is to restart the write if an EINTR has been observed.
Closes GH-11510.
This reverts commit 7eb3e9cd17.
Although the fix follows the spec, it causes issues because a lot of old
code assumes the incorrect behaviour PHP had since a long time.
We cannot do this yet, especially not in a stable release.
We revert this for the time being.
See GH-11428.
The problem is the usage of zval_get_long(). In particular, if the
string is non-numeric the result of zval_get_long() will be 0 without
giving an error or warning. This is misleading for users: users get the
impression that they can use strings to access the map because it
coincidentally works for the first item (which is at index 0). Of
course, this fails with any other index which causes confusion and bugs.
This patch adds proper support for using string offsets while accessing
the map. It does so by detecting if it's a non-numeric string, and then
using the getNamedItem() method instead of item(). I had to split up the
array access implementation code for DOMNodeList and DOMNamedNodeMap
first to be able to do this.
Closes GH-11468.
The NULL namespace is only correct when there is no default namespace
override. When there is, we need to manually set it to the empty string
namespace.
Closes GH-11428.
We'll use the DOM wrapper version of libxml2 instead of the regular one.
It's conforming to the behaviour we expect of DOM.
Most of this patch is tests.
I based and extended the tests on the code attached with the aforementioned
bug reports. Therefore the credits for the tests:
Co-authored-by: hilse at web dot de
Co-authored-by: robin2008 at altruists dot org
Co-authored-by: sgunderson at bigfoot dot com
We'll also change the searching point of the internal reconciliation to
start at the top of the added tree to avoid redundant work now that the
function is changed.
Closes GH-11454.
* Fix type confusion and parent reference
* Manually manage the lifetime of the parent
* Add regression tests
* Break out to a helper, and apply the use-after-free fix to xpath
Closes GH-11402.
IPv6 addresses are valid entries in subjectAltNames. Certificate
Authorities may issue certificates including IPv6 addresses except
if they fall within addresses in the RFC 4193 range. Google and
CloudFlare provide IPv6 addresses in their DNS over HTTPS services.
Internal CAs do not have those restrictions and can issue Unique
local addresses in certificates.
Closes GH-11145
From the moment an ID is created, libxml2's behaviour is to cache that element,
even if that element is not yet attached to the document. Similarly, only upon
destruction of the element the ID is actually removed by libxml2.
Since libxml2 has such behaviour deeply ingrained in the library, and uses the
cache for various purposes, it seems like a bad idea and lost cause to fight it.
Instead, we'll simply walk the tree upwards to check if the node is attached to
the document.
Closes GH-11369.
The test was amended from the original issue report. For the test:
Co-authored-by: php@deep-freeze.ca
The problem is that the regular dom_reconcile_ns() only works on a
single node. We actually have to reconciliate the whole tree in case a
fragment was added. This also required to move some code around such
that this special case could be handled separately.
Closes GH-11362.
It's a type confusion bug. `zend_make_callable` may change the function name
of the fci to become an array, causing a crash in debug mode on
`zval_ptr_dtor_str(&fci.function_name);` in `dom_xpath_ext_function_php`.
On a production build it doesn't crash but only causes a leak, because
the array elements are not destroyed, only the array container itself
is. We can use the nogc variant because it cannot contain cycles, the
potential array can only contain 2 strings.
Closes GH-11350.
Fail to clobber_error only when the argv is a non-contiguous area
Don't increment the end_of_error if a non-contiguous area is encountered in environ
Closes GH-11247
We could end up in an invalid hierarchy, resulting in infinite loops and
eventual crashes if we don't check for the DOM hierarchy validity.
Closes GH-11344.
Spec link: https://dom.spec.whatwg.org/#concept-getelementsbytagnamens
Spec says we should match any namespace when '*' is provided. This was
however not the case: elements that didn't have a namespace were not
returned. This patch fixes the error by modifying the namespace check.
Closes GH-11343.
I chose to check for the value of lock_file instead of checking the
file_cache_only, because it is probably a little bit faster and we're
going to access the lock_file variable anyway. It's also more generic.
Closes GH-11341.
Not explicitly documenting the possibility of returning DOMElement causes
the Intelephense linter (a popular PHP linter with ~9 million downloads:
https://marketplace.visualstudio.com/items?itemName=bmewburn.vscode-intelephense-client)
to think this code is bad:
$xp->query("whatever")->item(0)->getAttribute("foo");
DOMNode does not have getAttribute (while DOMElement does).
Documenting the DOMElement return type should fix Intelephense's linter.
Closes GH-11342.
We can't directly call xmlNodeSetContent, because it might encode the string
through xmlStringLenGetNodeList for types
XML_DOCUMENT_FRAG_NODE, XML_ELEMENT_NODE, XML_ATTRIBUTE_NODE.
In these cases we need to use a text node to avoid the encoding.
For the other cases, we *can* rely on xmlNodeSetContent because it is either
a no-op, or handles the content without encoding and clears the properties
field if needed.
The test was taken from the issue report, for the test:
Co-authored-by: ThomasWeinert <thomas@weinert.info>
Closes GH-10245.
This replaces the implementation of before and after with one following
the spec very strictly, instead of trying to figure out the state we're
in by looking at the pointers. Also relaxes the condition on text node
copying to prevent working on a stale node pointer.
Closes GH-11299.
The break is outside the if, so if it succeeds or not this will always
stop after the first loop iteration instead of trying more allocators if
the first one fails.
Closes GH-11306.
