Fix #74267: segfault with streams and invalid data
If the current character is a line break character, it cannot be a tab
or space character, so we would always fail with an invalid sequence
error. Obviously, these `scan_stat == 4` conditions are meant to be
exclusive.
Furthermore, if `in_pp == NULL || in_left_p == NULL` is true, we hit a
segfault if we are not returning right away. Obviously, the additional
constraints don't make sense, so we remove them.
Allow defining of uname value for reproducible builds
Extend configure.ac to accept PHP_UNAME as env variable to set the value of the
PHP_UNAME define in a reproducible manner. This allows distributions to set a
fixed value for php_uname and keep the default behaviour if PHP_UNAME is not
set.
Fix #79664: PDOStatement::getColumnMeta fails on empty result set
As its name suggests, `sqlite3_data_count` returns the number of
columns in the current row of the result set; we are interested in the
number of columns regardless of the current row, so we have to use
`sqlite3_column_count` instead.
As of PHP 7.3.0, `sapi_cli_single_write()` is supposed to return `< 0`
on failure, but `fwrite()` returns a `size_t`, and signals error by
setting the stream's error indicator. We have to cater to that.
* Deactivate potentially remaining watchpoints after REPL
Otherwise the memory could still be protected, resulting in segfaults
during shutdown.
* NULL zend_handlers_table after freeing
As of commit 4130fe4[1], the `zend_handlers_table` is explicitly
freed in the `zend_vm_dtor()`. Since phpdbg (and maybe some other
SAPIs) may restart the engine afterwards, we have to make sure that
the table is also NULLed.
* Only set context option if there is a context
In other words, we must not follow the null pointer.
* Cater to file handles without attached console
File handles do not necessarily have an attached console (for
instance, pipes do not), in which case `GetConsoleScreenBufferInfo()`
fails. In this case we set a default value (`40`) for lines like on
other systems.
On startup, PHP deliberately changes the floating point control word to
enforce binary64 format for the calculations for best consistency
across platforms. However, this is unnessary for x86_64 architectures,
because in this case SSE instructions are used by default, and there is
no good reason to pass `-mfpmath=i387` or such.
Therefore, we can skip the modification, which has the benefit that
system libraries are free to work in the mode of their liking.
Nikita Popov [Tue, 26 May 2020 12:59:40 +0000 (14:59 +0200)]
Respect typed references in catch assignment
I decided to null out EG(exception) early here, which means only
the exception from the dtor / ref assign is preserved, and the
previous exception is not chained in. This is more robust, and
I don't think this situation is common enough to be bothered about
the precise behavior.
Nikita Popov [Tue, 26 May 2020 12:06:36 +0000 (14:06 +0200)]
Fix zend_assign_to_typed_ref() implementation
There was some confusion going on here regarding the original
value vs the copied value.
I've dropped the needs_copy variable, because this code is not
inlined, so it would always be true anyway.
What we need to do is perform a move-assignment of the copied
value (in which case we don't care about performing the assignment
before destroying garbage), and destroying the original value
for the VAR/TMP cases. This is a bit complicated by the fact that
references are passed in via a separate ref variable, so we can't
just ptr_dtor the original variable.
On startup, PHP deliberately changes the floating point control word to
enforce binary64 format for the calculations for best consistency
across platforms. However, this is unnessary when compiling under
`__SSE__`, because in this case the x87 instructions are not used.
Therefore, we can skip the modification, which has the benefit that
system libraries are free to work in the mode of their liking.
Fix #79615: Wrong GIF header written in GD GIFEncode
The color resolution is expected in bits 4-6 of the packed fields byte
of the logical screen descriptor (byte 10 of the GIF data stream),
according to the specification[1], section 18.
Nikita Popov [Wed, 20 May 2020 08:55:36 +0000 (10:55 +0200)]
Fix static property indirections in file cache
If the class is already linked, we need to serialize and
unserialize INDIRECTed static properties. Normally these would
be set up when copying from cache.
Since the member is not used in `OnUpdateEol()` that's not really an
issue, but still it's confusing to apparently have two INI settings
targeting the same member.
Xinchen Hui [Fri, 15 May 2020 07:36:51 +0000 (15:36 +0800)]
Merge branch 'PHP-7.4' of git.php.net:/php-src into PHP-7.4
* 'PHP-7.4' of git.php.net:/php-src:
Fix #79557: extension_dir = ./ext now use current directory for base
Fix #79596: MySQL FLOAT truncates to int some locales
[ci skip] Fix NEWS
Fix #79557: extension_dir = ./ext now use current directory for base
For some reason, `ImageLoad()` fails to load images with a relative
path starting with `.\` or `./`. We work around this issue by
stripping those leading characters.
We add the missing release dates, the NEWS regarding the latest CVE
fixes, and move the entry for bug #79536 to 7.4.7 because it didn't
make it into 7.4.6.
Gerard Roche [Wed, 13 May 2020 18:57:54 +0000 (19:57 +0100)]
Fix lcov genhtml: ERROR: cannot read [file]
lcov is emitting several errors for generated regex files that have no code
coverage data. The fix is to add the files to the lcov exlusion list.
This is not an issue for CI because it uses gcovr to generate code coverage.
The errors:
Processing ext/date/lib/parse_date.gcda
geninfo: WARNING: could not open /home/code/vendor/php/php-src/parse_date.re
geninfo: WARNING: could not open /home/code/vendor/php/php-src/<stdout>
geninfo: WARNING: some exclusion markers may be ignored
Processing ext/date/lib/parse_tz.gcda
Processing ext/date/lib/tm2unixtime.gcda
Processing ext/date/lib/parse_iso_intervals.gcda
geninfo: WARNING: could not open /home/code/vendor/php/php-src/<stdout>
geninfo: WARNING: could not open /home/code/vendor/php/php-src/parse_iso_intervals.re
geninfo: WARNING: some exclusion markers may be ignored
...
genhtml: ERROR: cannot read /home/code/vendor/php/php-src/parse_date.re
Processing file /home/code/vendor/php/php-src/parse_date.re
make: *** [Makefile:443: lcov-html] Error 2
To solve bug #70886, the test uses random keys to prevent collisions;
however, this is not guaranteed, and as such it may even collide with
other tests in the shmop test suite. The proper solution would be to
use a single key (which could be randomly generated), but to actually
`shmop_close()` after each `shmop_delete()`. This would, however, not
work on Windows due to bug #65987. Therefore we use three different
keys for now.
* PHP-7.3:
Fix #78876: Long variables cause OOM and temp files are not cleaned
Fix #78875: Long filenames cause OOM and temp files are not cleaned
Update NEWS for 7.2.31
Update CREDITS for PHP 7.2.30
Update NEWS for PHP 7.2.30
* PHP-7.2:
Fix #78876: Long variables cause OOM and temp files are not cleaned
Fix #78875: Long filenames cause OOM and temp files are not cleaned
Update NEWS for 7.2.31
Update CREDITS for PHP 7.2.30
Update NEWS for PHP 7.2.30
Fix #78875: Long filenames cause OOM and temp files are not cleaned
We must not cast `size_t` to `int` (unless the `size_t` value is
guaranteed to be less than or equal to `INT_MAX`). In this case we can
declare `array_len` as `size_t` in the first place.
We must not attempt to access arbitrary union members when retrieving
debug info, because that may not be valid. Therefore we do no longer
dereference pointer types inside of unions, but report their address as
string in `%p` format instead.
Alex Dowad [Sun, 10 May 2020 12:57:12 +0000 (14:57 +0200)]
Don't check directory atime in lstat_stat_variation10.phpt test
This is a funny one. I discovered that lstat_stat_variation10.phpt was failing every
now and again when the PHP test suite was run on my dev PC. The output from the failing
test showed that the atime (access time) of the directory created in the test was changing
between these lines:
Could is_dir() be accessing the directory and changing the atime? strace showed that is_dir
was only issuing a single stat() syscall. Could stat() change the atime? No, no, that would
just be perverse. Nobody would be stupid enough to implement the kernel in that way.
Checked the kernel source, found that the function called when atime needs to be updated
appears to be touch_atime(). Broke out the BCC kernel tracing tools and ran this one
while running the flaky test case in a loop:
Inspecting the results showed that something called "git_thread" was occcasionally updating
the atime on the directory in question!! What on earth...???
The PID shown by trace revealed that this was a background thread for Sublime Text 3.
Sublime now has git integration and shows when there are untracked or modified files. It
seems that it uses a background thread to regularly scan the project directory and look
for new and modified files. This was causing the atime to change.
Even though other developers may not be running ST3, there are any number of reasons why
a background process might recurse through various directories and could cause the atime
to change unexpectedly. Therefore, update the test case so it doesn't fail in such cases.
We map the POSIX semantics of `IPC_PRIVATE` by creating unnamed file
mapping objects on Windows. While that is not particularly useful for
ext/shmop, which is the only bundled extension which uses `shmget()`,
it may be useful for external extensions.
On Windows, reusing/sharing of OPcache instances with different
configuration is not necessarily supported, so we have to make that it
does not happen for the clean scripts, by using `$orig_ini_settings`
instead of `$clean_params`.
Merge branch 'PHP-7.4' of git.php.net:/php-src into PHP-7.4
* 'PHP-7.4' of git.php.net:/php-src:
Fix #79532: sizeof off_t can be wrong
Make 045.phpt busy wait
Revert "Fix #79065: DOM classes do not expose properties to Reflection"
Bump version
Fix #79065: DOM classes do not expose properties to Reflection
Fix #79470: PHP incompatible with 3rd party file system on demand