With that, also fixed bug #68297 (Application Popup provides too few
information) as a better error message is provided to the event log.
In the second case, the condition for display_startup_error was removed. The
condition was added as a fix for bug #30760 which was preventing the
MessageBox to appear. When display_startup_error=on, the error will be seen
on the console. But when running under a webserver it'll probably get lost,
so we need to log it other way into the event log (would be done automatically
when message box was used, but that would eventually cause issues of blocked
execution).
Generally speaking - any MessageBox or other graphical element is a potential
issue and that was repeatedly reported. Graphical elements shouldn't be used
in the core. Even being a rare one it can cause a bad situation where the
server is blocked. Yet some places have to cleaned up.
* PHP-5.5:
update NEWS
Update the VM generation script, per Bob.
Update NEWS after rebase.
Add BEGIN_EXTERN_C() and END_EXTERN_C() to .h files missing them.
* pull-request/840:
Update the VM generation script, per Bob.
Update NEWS after rebase.
Add BEGIN_EXTERN_C() and END_EXTERN_C() to .h files missing them.
* PHP-5.5:
update NEWS
Only destruct if EG(active) in zend_shutdown(). (bug #65463, #66036)
Fix typo from commit 32314f6b6
Fix destruction order in zend_shutdown (bug #65463, #66036)
* PHP-5.4:
update NEWS
Only destruct if EG(active) in zend_shutdown(). (bug #65463, #66036)
Fix typo from commit 32314f6b6
Fix destruction order in zend_shutdown (bug #65463, #66036)
* pull-request/770:
Only destruct if EG(active) in zend_shutdown(). (bug #65463, #66036)
Fix typo from commit 32314f6b6
Fix destruction order in zend_shutdown (bug #65463, #66036)
- Added ZEND_INI_SCANNER_TYPED mode for parse_ini_string() and parse_ini_file()
- Added NULL_NULL token to separate it from BOOL_FALSE and BOOL_TRUE
- Added zend_ini_copy_typed_value() function for zval initialisation
- Updated RETURN_TOKEN() to observe scanner_mode
If Apache or a similar SAPI receives a signal during PHP processing
it calls zend_shutdown() without calling shutdown_executor().
#65463: If a module like Gearman or Memcached is loaded,
in the unfixed version it is unloaded by zend_destroy_modules() before the
CG(CLASS_TABLE) is destructed. When CG(CLASS_TABLE) is destructed,
any pointers to methods (specifically around destruction) in the unloaded
module's .so are now dangling and the process segfaults.
#66036: Any subclasses of an internal class like ArrayObject need
to be destructed in order: subclass first and then the internal class. In the
unfixed version zend_shutdown() clears the CG(CLASS_TABLE) from the head
of the list onwards, so internal classes are destructed first and user-defined
classes last. Internal classes are alloc/deallocated with malloc/free while
user-defined classes with emalloc/efree. If there's shared data between them
then efree() could be called instead of free() leading to a seg-fault.
This implements the original functionality of php_splice, but
as an in-place operation, thus avoiding copying the HT.
This is much faster (~10x) if the splice removes a small portion
of the array and doesn't insert many elements.
The implementation differs from the original in array.c in that it
rehashes the hashtable in the same loop. This is approximately two
times faster (not counting the rare case of a purely associative
array).
The interruption handling was normalized to wrap the entire deletion
operation (instead of leaving out the destructor call and/or the
deallocation) per the recommendation of somebody (don't remember who)
familiar with zend signals.
There is an always-inlined variant of the function for use in
the main deletion function, to ensure there is no performance
impact.
Also remove lies in the comment above the function. apply_deleter
is not safe against modification, if the modification involves
removing the next bucket.
Also modified the implementation of zend_hash_graceful_destroy()
to be fully graceful (the reverse variant already was).
This commit disallows the use of trailing positional arguments
after argument unpacking was used. The following calls are no
longer valid:
fn(...$array, $var);
fn(...$array1, $var, ...$array2);
However, all of the following continue to be valid:
fn($var, ...$array);
fn(...$array1, ...$array2);
fn($var, ...$array1, ...$array2);
The reason behind this change is a stack allocation issue pointed
out by Dmitry: As of PHP 5.5 the stack necessary for pushing
arguments is precomputed and preallocated, as such the individual
SEND opcodes no longer verify that there is enough stack space.
The unpacked arguments will occupy some of that preallocated
space and as such following positional arguments could write past
a stack page boundary.
An alternative resolution for this issue is to ensure that there
is enough space for the remaining arguments in the UNPACK opcode.
However making this allocation precise (rather than using a
conversative over-estimate) would require some effort. Given that
this particular aspect of the feature wasn't very popular in the
first place, it doesn't seem worth the effort.
Instead of storing the argument number in the znode of the parameter
list, store it in fcall->arg_num. This mainly cleans up the parameter
parsing code, which previously had to duplicate all rules (this
becomes more excessive as more features are added, e.g. named params
would already require a minimum of 14 rules...)
Instead of directly pushing the zend_function* onto the
function_call_stack, push this structure. This allows us to store
additional data on this stack.
Fixed recognition of the operator
Added opcode, still doing multiply instead of pow()
opcode now always returns int(42)
The right answer, but always a float
Yanked code from pow() implementation.
Should not handle negative long as exponent ourselves
Added test cases from pow()
Moved precedence higher than '~'
Added GMP operator overloading
Added ZEND_ASSIGN_POW (**=) operator.
Added pow() as a language construct.
Adjusted test cases for changed precedence.
Reduced pow() to shell function around ZEND_API pow_function()
Reduced test case to only contain edge cases
Added overloading test case
Moved unary minus above T_POW
Revert "Added pow() as a language construct."
Bad bad bad idea.
This reverts commit f60b98cf7a8371233d800a6faa286ddba4432d02.
Reverted unary minus behaviour due to previous revert.
Convert arrays to int(0)
Exponent with array as a base becomes int(0)
Rebase against master
Fixed tokenizer test case
If multiple unpacks were used (or mixed with normal arguments)
parts of the arguments could land on different stack pages. If
this occurs the arguments will now be copied to a new stack page.
The code used to do this is copied verbatim from the PHP 5.4 branch
and only modified to reduce the amount of inlined code.
Visual Studio 2012 includes sanity checks for C++11 features, see
http://msdn.microsoft.com/en-us/library/vstudio/bb531344(v=vs.110).aspx
To fix the 'inline' keyword redefinition for C++ in debug mode, the
new macros ZEND_WIN32_KEEP_INLINE is introduced, ZEND_WIN32_FORCE_INLINE is
automatically appended in release mode.
Visual Studio 2012 includes sanity checks for C++11 features, see
http://msdn.microsoft.com/en-us/library/vstudio/bb531344(v=vs.110).aspx
To fix the 'inline' keyword redefinition for C++ in debug mode, the
new macros ZEND_WIN32_KEEP_INLINE is introduced, ZEND_WIN32_FORCE_INLINE is
automatically appended in release mode.
std_compare_objects immidiately returned 0 if the property tables
of both objects contain NULL at some index. Thus it would report
objects as equal even though properties following after that
differ.
This piece of code seems to retain compatibility with some windows
versions before 2000. Today it's not relevant anymore and only
produces a warning C4273 because of the conflicting prototype. In
VC9 the declaration is present in winbase.h:4142, but available
is it already in winxp. Here's the doc link
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680345(v=vs.85).aspx
* PHP-5.5:
stop warnings from unused opcode map
- BFN
- Fixed bug #66311 (Stack smashing protection kills PDO/ODBC queries) patch by: michael at orlitzky dot com
Included new .c file in build too
Fixed little typo in zend_vm_gen.php
Moved to new file, killing a lot of warnings
That way extensions etc. don't have to maintain their own lists anymore.
Also as phpdbg is included and needs such a map, it'd be counterproductive to need to change two things on every new opcode.
When Wincache or APC are installed, the resource IDs are not the same.
This is because Wincache takes a few resource objects for itself. As a
result, these tests become false positives.
On Windows boxes, the microtime precision is not granular enough
to reliably register a difference if two calls to uniqid() are made
concurrently. This is a fix to the uniqid() test to avoid the false
positive when run on Windows machines. Also, added a test to exercise
the 'more_entropy' variant of uniqid().
Functions registered using zend_register_functions instead of zend_module_entry.functions are not seen on reflection.
Ex: additional_functions from api_module_entry.
Ex: in CLI, dl, cli_set_process_title and cli_get_process_title
Note:
- also affects functions overrided in extension
(should be be reported in extension, where overrided, not in original extension)
- also allow extension to call zend_register_functions for various list
(instead of having a single bug list)
The 'result' argument of fast_add_function() may alias with either
of its operands (or both). Take care not to write to 'result' before
reading op1 and op2.
The 'result' argument of fast_add_function() may alias with either
of its operands (or both). Take care not to write to 'result' before
reading op1 and op2.
I'm not exactly sure whether this is the right way to fix it. The
question is whether Generator::throw() on a newborn generator (i.e.
a generator that is not yet at yield expression) should first advance to
the first yield and throw the exception there or whether it should
instead throw the exception in the caller's context.
The old behavior was to throw it at the start of the function (i.e.
the very first opcode), which causes issues like the one in #65764.
Effectively it's impossible to properly handle the exceptions in this
case.
For now I choose the variant where the generator advances to the
first yield before throwing, as that's consistent with how all other
methods on the Generator object currently behave. This does not
necessarily match the behavior in other languages, e.g. Python would throw
the exception in the caller's context. But then our send() method already
has this kind of deviation, so it stays internally consistent at least.
