According to @cmb69, PHP does not require VLA support
(https://github.com/php/php-src/pull/10304#discussion_r1069343092).
VLAs are a bad idea for several reasons, so let's get rid of them.
Two of the VLAs were probably unintended; unlike C++, C doesn't have
the concept of "constant expressions", so an array with a "const"
length is technically still a VLA. This is fixed by removing the
"const" variable, and using sizeof() instead.
(cherry picked from commit ff2a211d55)
There have been misterious macOS failures with the following error for a long
time, which would usually happen 1-2x per nightly run:
> The hosted runner lost communication with the server. Anything in your
> workflow that terminates the runner process, starves it for CPU/Memory, or
> blocks its network access can cause this error.
After way too much debugging, it looks like this is caused by the two fpm tests
skipped in this commit. When there's a failure, the responsible test will run
for at least 120 seconds until the job is eventually killed by GitHub Actions.
It's not clear yet why the tests stall.
Debugging this is a PITA because the GitHub Actions log gets partially lost for
killed jobs. It took an external log server to actually figure out where the job
fails. Let's disable the tests first to be sure this actually solves the issue.
Apache only generates REDIRECT_STATUS, so explicitly check for that
if the server name is Apache, don't allow other variable names.
Furthermore, redirect.so and Netscape no longer exist, so
remove those entries as we can't check their server name anymore.
We now also check for the configuration override *first* such that it
always take precedence. This would allow for a mitigation path if
something like this happens in the future.
It's no use trying to work around whatever the operating system and Apache
do because we'll be fighting that until eternity.
Change the skip_getopt condition such that when we're running in
CGI or FastCGI mode we always skip the argument parsing.
This is a BC break, but this seems to be the only way to get rid of this
class of issues.
The original code is error-prone due to the "best fit mapping" that
happens with the argument parsing but not with the query string.
When we get a non-ASCII character, try to remap it and see if it becomes
a hyphen.
An alternative approach is to create a custom main `wmain` receiving
wide-character variations that does the ANSI transformation with the
best-fit mapping, but that's more error-prone and could cause unexpected
breakage.
Another alternative was just don't doing this check altogether and
always check for `cgi || fastcgi` instead, but that breaks real-world
use-cases.
Have to use file_put_contents() instead of --FILE-- because we have to
actually load it using the exec command, *and* have to make multiple
files, and note that we can only load files relative from the current
directory, so we can't rely on files being in the sapi/phpdbg/tests
folder.
Closes GH-12680.
The temporary HashTable has a destructor that releases the string held
by the entry's value. However, browscap_intern_str(_ci) only incremented
the refcount for the reference created by the return value. As the
HashTable is only used during parsing, we don't need to manage the
reference count of the value anyway, so get rid of the destructor.
This is triggerable in two cases:
- When using php_admin_value to set the ini at the activation stage
- When running out of space for the opcache-interned strings
Closes GH-12634.
Currently the PHP Development Server appends a Date header in the
response, despite already set from user code.
Added a check condition before append the header, and a test file.
Closes GH-12363.
After preloading has executed, the executor globals for class_table and
function_table are still referring to the values during preloading.
If no request happens after that then these values will remain dangling
pointers. If then the -v option on CLI or -h option (and possibly
others) on CGI is provided, there is a double free.
Fix it by nulling the pointers explicitly after preloading has finished
to fix it for all SAPIs.
Closes GH-12311.
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.
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
This is to prevent after free accessing of the child event that might
happen when child is killed and the message is delivered at that same
time.
Also fixes GH-10889 and properly fixes GH-8517 that was not previously
fixed correctly.
This happens when there are spaces are in the path info. The reason is
that Apache decodes the path info part in the SCRIPT_NAME as per CGI
RFC. FPM tries to strip path info from the SCRIPT_NAME but the
comparison is done against SCRIPT_FILENAME which is not decoded. For
that to work we have to decode it before comparison if there is any
encoded character.
Closes GH-10869
Fixes GH-8646
See https://github.com/php/php-src/issues/8646 for thorough discussion.
Interned strings that hold class entries can get a corresponding slot in map_ptr for the CE cache.
map_ptr works like a bump allocator: there is a counter which increases to allocate the next slot in the map.
For class name strings in non-opcache we have:
- on startup: permanent + interned
- on request: interned
For class name strings in opcache we have:
- on startup: permanent + interned
- on request: either not interned at all, which we can ignore because they won't get a CE cache entry
or they were already permanent + interned
or we get a new permanent + interned string in the opcache persistence code
Notice that the map_ptr layout always has the permanent strings first, and the request strings after.
In non-opcache, a request string may get a slot in map_ptr, and that interned request string
gets destroyed at the end of the request. The corresponding map_ptr slot can thereafter never be used again.
This causes map_ptr to keep reallocating to larger and larger sizes.
We solve it as follows:
We can check whether we had any interned request strings, which only happens in non-opcache.
If we have any, we reset map_ptr to the last permanent string.
We can't lose any permanent strings because of map_ptr's layout.
Closes GH-10783.
Fixes GH-10715
When a string starting with a NUL character is passed to
phpdbg_vprint(), the vasprintf() will return that 0 characters have been
printed. This causes msglen == 0. When phpdbg_process_print() is called
with a message of length 0, the -1 to check for '\n' will perform an out
of bounds read. Since nothing is printed anyway for msglen == 0, it
seems best to just skip the printing routine for this case.
Closes GH-10720.
