Mostly, extensions will use `PHP_VERSION` and `PHP_VERSION_ID`
respectfully but sometimes they want to grab the version at run-time
rather than at compile-time. For example, extensions which distribute
pre-built binaries may want this.
This is an alternative implementation for GH-10406 that resets the
has_buffered_data flag after finishing stream read so it does not impact
other ops->read use like for example php_stream_get_line.
Closes GH-11421
This adds support for the completed event. Since the read handler could
be entered twice towards the end of the stream we remember what the eof
flag was before reading so we can emit the completed event when the flag
changes to true.
Closes GH-10505.
| 732 | ts->mode = mode && mode[0] == 'r' && mode[1] != '+' ? TEMP_STREAM_READONLY : 0;
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
Although mode is already dereference on line 723 in the call to strlen()
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.
The TSRM keeps a hashtable mapping the thread IDs to the thread resource pointers.
It's possible that the thread disappears without us knowing, and then another thread
gets spawned some time later with the same ID as the disappeared thread.
Note that since it's a new thread the TSRM key pointer and cached pointer will be NULL.
The Apache request handler `php_handler()` will try to fetch some fields from the SAPI globals.
It uses a lazy thread resource allocation by calling `ts_resource(0);`.
This allocates a thread resource and sets up the TSRM pointers if they haven't been set up yet.
At least, that's what's supposed to happen. But since we are in a situation where the thread ID
still has the resources of the *old* thread associated in the hashtable,
the loop in `ts_resource_ex` will find that thread resource and assume the thread has been setup
already. But this is not the case since this thread is actually a new thread, just reusing the ID
of the old one, without any relation whatsoever to the old thread.
Because of this assumption, the TSRM pointers will not be setup, leading to a
NULL pointer dereference when trying to access the SAPI globals.
We can easily detect this scenario: if we're in the fallback path, and the pointer is NULL,
and we're looking for our own thread resource, we know we're actually reusing a thread ID.
In that case, we'll free up the old thread resources gracefully (gracefully because
there might still be resources open like database connection which need to be
shut down cleanly). After freeing the resources, we'll create the new resources for
this thread as if the stale resources never existed in the first place.
From that point forward, it is as if that situation never occurred.
The fact that this situation happens isn't that bad because a child process containing
threads will eventually be respawned anyway by the SAPI, so the stale thread resources
won't remain forever.
Note that we can't simply assign our own TSRM pointers to the existing
thread resource for our ID, since it was actually from a different thread
(just with the same ID!). Furthermore, the dynamically loaded extensions
have their own pointer, which is only set when their constructor is
called, so we'd have to call their constructor anyway...
I also tried to call the dtor and then the ctor again for those resources
on the pre-existing thread resource to reuse storage, but that didn't work properly
because other code doesn't expect something like that to happen, which breaks assumptions,
and this in turn caused Valgrind to (rightfully) complain about memory bugs.
Note 2: I also had to fix a bug in the core globals destruction because it
always assumed that the thread destroying them was the owning thread,
which on TSRM shutdown isn't always the case. A similar bug was fixed
recently with the JIT globals.
Closes GH-10863.
This change restores the old behaviour for the server socket streams
that don't support IO. This is now stored in the stream flags so it can
be later used to do some other decisions and possibly introduce some
better error reporting.
Closes GH-10877
Struct members require some alignment based on their type. This means
that if a struct member is not aligned, there will be a hole created by
the compiler in the struct, which is wasted space. This patch reorders
some of the most commonly used structs, but in such a way that the
fields which were in the same cache line still belong together.
The only exception to this is exception_ignore_args, which was
temporally not close to nearby members, and as such I placed
it further up to close a hole.
On 64-bit Linux this gives us the following shrinks:
* zend_op_array: 248 -> 240
* zend_ssa_var: 56 -> 48
* zend_ssa_var_info: 48 -> 40
* php_core_globals: 672 -> 608
* zend_executor_globals: 1824 -> 1792
On 32-bit, the sizes will either remain the same or will result in
smaller shrinks.
The tsrm_startup() function is currently always called with expected_threads = 1.
This means that the hashtable used in the TSRM will only contain a single bucket,
and all thread resources will therefore be in the same linked list.
So it's not really a hashtable right now, even though it's supposed to be.
This patch adds a function tsrm_startup_ex() which takes the expected
thread count as an argument. It also keeps the tsrm_startup() function
so there are no BC breaks.
In the Apache SAPI we query how many threads we have, and pass that to
the tsrm_startup_ex() function.
`zend_rc_debug` is not a type and does not really belong in
`zend_types.h`; this allows using `ZEND_RC_MOD_CHECK()` without
including the huge `zend_types.h` header and allows decoupling
circular header dependencies.
Fixes GH-10692
php_fopen_primary_script() does not initialize all fields of
zend_file_handle. So when it fails and when fastcgi is true, the
zend_destroy_file_handle() function will try to free uninitialized
pointers, causing a segmentation fault. Fix it by zero-initializing file
handles just like the zend_stream_init_fp() counterpart does.
Closes GH-10697.
`zend_uchar` suggests that the value is an ASCII character, but here,
it's about very small integers. This is misleading, so let's use a
C99 integer instead.
On all architectures currently supported by PHP, `zend_uchar` and
`uint8_t` are identical. This change is only about code readability.
* Zend/zend_enum: make `forbidden_methods` static+const
* main/php_syslog: make `xdigits` static
* sapi/fpm: make several globals `const`
* sapi/phpdbg: make `OPTIONS` static
* sapi/phpdbg/help: make help texts const
* sapi/cli: make `template_map` const
* ext/ffi: make `zend_ffi_types` static
* ext/bcmath: make `ref_str` const
* ext/phar: make several globals static+const
