ex->call is only set for user calls, we shouldn't access it here.
zend_unfinished_execution_gc_ex wouldn't actually use it for internal calls, so
it didn't cause any serious issues.
Closes GH-11208
resource would stay uninitialized if the first call to zend_parse_parameters
fails, but the value is still passed to phar_add_file(). It's not used there if
cont_str is provided and so didn't cause any issues.
Closes GH-11202
The comment was incorrect. Zval ASTs store their lineno in u2, but u2 does not
get copied in ZVAL_COPY. This triggers use-of-uninitialized errors with MSAN.
Unfortunately, I don't have a simple reproducer.
It's possible to categorise the failures into 2 categories:
- Changed error message. In this case we either duplicate the test and
modify the error message. Or if the change in error message is
small, we use the EXPECTF matchers to make the test compatible with both
old and new versions of libxml2.
- Missing warnings. This is caused by a change in libxml2 where the
parser started using SAX APIs internally [1]. In this case the
error_type passed to php_libxml_internal_error_handler() changed from
PHP_LIBXML_ERROR to PHP_LIBXML_CTX_WARNING because it internally
started to use the SAX handlers instead of the generic handlers.
However, for the SAX handlers the current input stack is empty, so
nothing is actually printed. I fixed this by falling back to a
regular warning without a filename & line number reference, which
mimicks the old behaviour. Furthermore, this change now also shows
an additional warning in a test which was previously hidden.
[1] 9a82b94a94
Closes GH-11162.
The error happens when the PEM contains a public key, as it will be
first tried to be parsed as a certificate. The parsing as a certificate
fails, which then leads to a corresponding error tracked by PHP with
the next call to php_openssl_store_errors().
This change introduces an error marking to be able to reset the stored
errors to the state before trying the certificate.
Closes GH-11055
PKCS7_NOOLDMIMETYPE to use Content-Type application/pkcs7-mime
OPENSSL_CMS_OLDMIMETYPE to use Content-Type application/x-pkcs7-mime
SMIME_write_PKCS7 and SMIME_write_CMS are using SMIME_write_ASN1_ex.
The Content-Type application/x-pkcs7-mime is generated with the flag SMIME_OLDMIME (0x400).[^1]
SMIME_write_PKCS7 set SMIME_OLDMIME by default.[^2]
SMIME_write_CMS does not.[^3]
I picked OPENSSL_CMS_OLDMIMETYPE over OPENSSL_CMS_NOOLDMIMETYPE because that's what the flag actually does.
[^1]: 9a2f78e14a/crypto/asn1/asn_mime.c (L248-L251)
[^2]: 9a2f78e14a/crypto/pkcs7/pk7_mime.c (L41-L43)
[^3]: 9a2f78e14a/crypto/cms/cms_io.c (L93)
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
I grepped for php_printf cases in main/ and sapi/ and converted the
cases which clearly indicate errors to fprintf(stderr, ...), like
suggested in the linked issue.
Closes GH-11163.
It's possible that the server already sent in more data than just the headers.
Since the stream only accepts progress increments after the headers are
processed, the already read data is never added to the process.
We account for this by adjusting the progress counter by the difference of
already read header data and the body.
For the test:
Co-authored-by: aetonsi <18366087+aetonsi@users.noreply.github.com>
Closes GH-10492.
- PGSQL_TRACE_SUPPRESS_TIMESTAMPS.
- PGSQL_TRACE_REGRESS_MODE to have a more verbose and observable
output to check possible regressions.
Close GH-11041
There are more places in zend_hash.c where the resize happened after some values on the HashTable struct were set.
I reordered them all, but writing a test for these would rely on the particular amount of bytes allocated at given points in time.
Since lowercasing and uppercasing is a common operation for both
internal purposes and userland purposes, it makes sense to implement a
NEON accelerated version for this.
I found no reason why this is done this way.
Of course this will allow users to do stupid stuff like
`fclose(STDOUT);` etc. but if they type in that code they clearly know
what they're doing...
Close GH-11169.
A negative value like -1 may overflow and cause incorrect results in the
timeout variable, which causes an immediate timeout. As this is caused
by undefined behaviour the exact behaviour depends on the compiler, its
version, and the platform.
A large overflow is also possible, if an extremely large timeout value
is passed we also set an indefinite timeout. This is because the timeout
value is at least a 64-bit number and waiting for UINT64_MAX/1000000
seconds is waiting about 584K years.
Closes GH-11183.
This patch preserves the scratch registers of the SysV x86-64 ABI by storing
them to the stack and restoring them later. We need to do this to prevent the
registers of the caller from being corrupted. The reason these get corrupted
is because the compiler is unaware of the Valgrind replacement function and
thus makes assumptions about the original function regarding registers which
are not true for the replacement function.
For implementation I used a GCC and Clang attribute. A more general
approach would be to use inline assembly but that's also less portable
and quite hacky. This attributes is supported since GCC 7.x, but the
target option is only supported since 11.x. For Clang the target option
does not matter.
Closes GH-10221.
We have lots of spurious failures in CI, many of them with the "all" CONFLICT.
We're limiting the retrying to specific error messages. In the future we may
also provide a FLAKY section to retry specific tests.
Closes GH-10892
