stream_get-line repeatedly calls php_stream_fill_read_buffer until
enough data is accumulated in buffer. However, when stream contains
filters attached to it, then each call to fill buffer essentially
resets buffer read/write pointers and new data is written over old.
This causes stream_get_line to skip parts of data from stream
This patch fixes such behavior, so fill buffer call will append.
There are two related changes here:
1. Also check for S_ISCHR/FILE_TYPE_CHAR when checking for pipes, so
that we detect ttys as well, which are also not seekable.
2. Always set position=-1 (i.e. ftell will return false) when a pipe
is detected. Previously position=0 was sometimes used, depending on
whether we're on Windows/Linux and whether the FD or FILE codepath
was used.
fcgi_accept_request function is supposed to call a FastCGI implementation's
on_accept hook when entering an "accepting" stage (that is right before
calling "accept"). This hook implementation (fpm_request_accepting) updates
a worker state to an "accepting" state which is effectively an "Idle" state,
and updates counters on the scoreboard of the corresponding pool (idle++,
active--).
But this is not done when listening for client connections on a named pipe on
Windows platform. In that case a combination of
ConnectNamedPipe/WaitForSingleObject is used (to be able to catch in_shutdown
as far as I understand), but it is nonetheless functionally equivalent to
"accept" call. Also by not calling on_hook neither a worker's state is updated
to "accepting" state nor scoreboard counters are updated.
There are a few parts here:
* opcache should not be blocking signals while invoking compile_file,
otherwise signals may remain blocked on a compile error. While at
it, also protect SHM memory during compile_file.
* We should deactivate Zend signals at the end of the request, to make
sure that we gracefully recover from a missing unblock and signals
don't remain blocked forever.
* We don't use a critical section in deactivation, because it should
not be necessary. Additionally we want to clean up the signal queue,
if it is non-empty.
* Enable SIGG(check) in debug builds so we notice issues in the future.
The php_stream_read() and php_stream_write() functions now return
an ssize_t value, with negative results indicating failure. Functions
like fread() and fwrite() will return false in that case.
As a special case, EWOULDBLOCK and EAGAIN on non-blocking streams
should not be regarded as error conditions, and be reported as
successful zero-length reads/writes instead. The handling of EINTR
remains unclear and is internally inconsistent (e.g. some code-paths
will automatically retry on EINTR, while some won't).
I'm landing this now to make sure the stream wrapper ops API changes
make it into 7.4 -- however, if the user-facing changes turn out to
be problematic we have the option of clamping negative returns to
zero in php_stream_read() and php_stream_write() to restore the
old behavior in a relatively non-intrusive manner.
By adding a flag to avoid forced fstat for includes. The two fstats
will happen back to back and we don't care about a possible
invalidation.
I was hoping to move this higher up in the stack and make the
ISREG check somewhere in fsizer of fixup, but this doesn't really
seem to be possible. E.g. an FP stdin handle will not be a regular
file but of course needs to be allowed. Additionally custom stream
wrappers may not implement this functionality.
If we're including a file via PHP streams, we're not going to trust
the reported file size anyway and populate in a loop -- so don't
bother determining the file size in the first place. Only do this
for non-tty HANDLE_FP now, which is the only case where this
information was used.
Disable buffering in PHP streams, to avoid storing and copying the
file contents twice.
This will call stream_set_option() on custom stream wrapper as
well, so the method needs to be implemented to avoid a warning.
Using mmap() is unsafe under concurrent modification. If the file
is truncated, access past the end of the file may occur, which will
generate a SIGBUS error. Even if the length does not change, the
contents may, which is a situation that the lexer certainly is not
prepared to deal with either.
Reproduce with test.php:
<?php
file_put_contents(__DIR__ . '/test.tpl',
'AAA<?php $string = "' .
str_repeat('A', mt_rand(1, 256 * 1024)) .
'"; ?>BBB' . "\r\n");
require_once __DIR__ . '/test.tpl';
And:
for ((n=0;n<100;n++)); do sapi/cli/php test.php & done
Instead of handling shebang lines by adjusting the file pointer in
individual SAPIs, move the handling into the lexer, where this is
both a lot simpler and more robust. Whether the shebang should be
skipped is controlled by CG(skip_shebang) -- we might want to do
that in more cases.
This fixed bugs #60677 and #78066.
These were part of the following decomissioned extensions:
- PHP_SYBASE part of the sybase extension
- PHP_MSQL_* part of the msql extension
- PHP_APACHE_* symbols were used in apache and apache_hooks sapis
- PHP_FHTTPD_* symbols part of old sapi/fhttpd
- PHP_MYSQL_* symbols were part of the legacy mysql extension
- Remove PHP_ORACLE_* symbols
These were part of the obsolete oracle extension that was moved to PECL
via f35af61ef8.
- PHP_OCI8_SHARED_LIBADD and PHP_OCI8_DIR were removed via
c33f88ccb0
And other are not used anywhere across the php-src codebase
Joe Watkins