In this case the progarm will be executed directly, without a shell.
On Linux the arguments are passed directly to execvp and no escaping
is necessary. On Windows we construct a command string using escaping
with the default Windows command-line argument parsing method described
at https://docs.microsoft.com/en-us/cpp/cpp/parsing-cpp-command-line-arguments.
Apart from avoiding the issue of argument escaping, passing an array
and bypassing shell has the advantage of allowing proper signal
delivery to the opened process (rather than the shell).
The actual leak is observed in ext/pdo_mysql/tests/bug_74376.phpt.
The persistent connection leaks because a refcount decrement on a
result is missed. The refcount decrement is missed because
free_result_contents is used, rather than free_result.
Looking at other uses of free_result_contents, it looks like they
could also suffer from this problem. Apart from one case,
free_result_contents is always used to release the result entirely
(I've adjusted the one differing case to only free meta), so I'm
moving most of the logic from free_result into free_result_contents.
The only difference is now that free_result will skip_result first.
If we're testing ini settings that cause startup failures, we'll
never get to that SKIPIF block...
Also change settings2param to return a value instead of modifying
(to a different type no less!) in place.
The strcoll function is defined in the C89 standard and should be
on today's systems always available via the <string.h> header.
https://port70.net/~nsz/c/c89/c89-draft.html#4.11.4.3
- Remove also SKIPIF strcoll check in test
The hash extension is always available since PHP-7.4. The symbol
HAVE_HASH_EXT is kept for BC reasons and removed in PHP-8.0.
This patch also removes the PHAR_HASH_OK since it is no longer
relevant.
In particular, make sure that everything using zmm is released
before zmm is shut down. phpdbg currently gets away with this,
because either a) its custom handlers are used and no auto-free
happens or b) the system allocator is used and no auto-free happens.
With the tracking allocator for asan this no longer works.
In this case we will use the system allocator, but still remember
all allocations and free them the same way that Zend MM does. This
allows us to accurately model leak behavior.
Enabled using USE_ZEND_ALLOC=0 USE_TRACKED_ALLOC=1.
As of libenchant 1.6.0 there is enchant_get_version()[1], so we use it,
if available, to show the actual enchant version in the PHP info. We
also drop the fake ENCHANT_VERSION_STRING altogether, but stick with
showing version 1.5.x if at least HAVE_ENCHANT_BROKER_SET_PARAM is
defined.
Future scope: we may consider requiring enchant 1.6.0 (or later), since
this has been released in April 2010, and likely is available
everywhere.
[1] <https://www.abisource.com/projects/enchant/>
Streams will be freed in an unpredictable order during shutdown.
Ignore explicit calls to php_stream_close() entirely to avoid
use-after-free -- instead let the stream resource destructor
deal with it. We have to account for a few special cases:
* Enclosed streams should be freed, as the resource destructor
will forward to the enclosing stream.
* Stream cookies also directly free streams, because we delegate
to the cookie destruction if one exists.
* Mysqlnd also directly frees streams, because it explicitly
removes stream resources (because mysqlnd!)
Some headers were checked multiple times in the main configure.ac file
and in the bundled extensions or SAPIs themselves. Also many of these
checks are then used accross other extensions or SAPIs so a central
configure.ac makes most sense for these checks.
This patch removes warnings when lexer and parser files are already
generated. For example, when downloading a PHP release. Realistically,
it is not so trivial to rebuild lexer and parser files without removing
them first. And considering that tarballs don't have cleaning tools
such as Git, this would require manual removali.
Related also to https://bugs.gentoo.org/593278
When tests are run concurrently using the -j option there might be a
change of failure and writing to the same directory from both tests.
Use test filenames for generated temp dirs
Fails for me locally due to different number of warnings with
different messages. Rather than adding more wildcards I'm dropping
this test entirely, as it doesn't seem to test anything particularly
useful.
(cherry picked from commit 84333cad67)
It seems that this code has a peculiar interpretation of "len",
where it actually points to the last character, not one past it.
So we need +1 here for that extra char and another +1 for the
terminating null byte.