Dereference the cached constant for Test::TEST as well (and not just
self::TEST).
Also improve the phpt file to test this case as well - previously
this only manifested with opcache enabled, due to literal sharing.
Additionally the Z_TYPE_P != IS_REFERENCE assertion is now moved
into the TMP_VAR fetching code (as it applies to more than just
property assignments.)
If a class is extended after the constant fetch has been cached
the cached value will be turned into a reference. On the next
fetch the polymorphic cache will return this reference, which
will be directly returned. The object assignment code then
dereferences this result and performs a shallow copy, which is
invalid for references. This subsequently leads to the constant
value being prematurely freed.
This is fixed by dereferencing the value returned from the
polymorphic cache. Furthermore the incorrect dereference from
in the object assignment code is replaced with an assertion that
we're dealing with a non-reference, so ensure that this kind of
problem cannot go unnoticed in the future.
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.
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.
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.
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)
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.
* upstream/PHP-5.6: (399 commits)
Fixed issue #115 (path issue when using phar). Fixed issue #149 (Phar mount points not working with OPcache enabled).
Added tests for PHAR/OPCahce incompatibilities
Update NEWS
Fixed bug #65947 (basename is no more working after fgetcsv in certain situation)
Update NEWS
Fixed Bug #66043 (Segfault calling bind_param() on mysqli)
NEWS entry
NEWS entry
Fix bug #65946 - pdo_sql_parser.c permanently converts values bound to strings
bump API versions
Add a couple more test cases to parse_url() tests
fix missing change from 'tcp_socket' to the more common 'server'
fix many parallel test issues
Cleanup temp test file
Revert "Fixed issue #115 (path issue when using phar)."
Update LiteSpeed SAPI code to V6.4
Fixed typo in Makefile.frag
updated NEWS
Remove outdate codes, make it clearer, although just a bit..
Update NEWS
...
Conflicts:
Zend/zend_compile.h
In context of static accesses like classname::$this, the string
"$this" should not be handled like a $this variable, but as an
identifier for a static variable.
Also fixes duplicate bugs #54054 and #42098.
Furthermore this fixes incorrect error messages thrown from code
running inside an error handler when a compilation is in progress.
The error file and line are now correctly associated with the
file/line of the executor, rather than the compiler.
Just changing the error level of the message from E_STRICT to
E_DEPRECATED. This comes one version later than the timeline
mentioned in the RFC.
Oddly, there were no tests for this ‘feature’. I added a simple
one.
Specifically, this checks if there are trait aliases defined in the class scope
before attempting to dereference the first trait alias. This handles the case
where a trait alias was used in a child trait but no aliases exist in the
concrete class.
This fixes bugs #65035 and #65161. In one of the bugs the issue is
that function_state.arguments is NULL, but the arg count is pushed
to the stack and the code tries to free it. In the other bug the
stack of the generator is freed twice, once in generator_close and
later during shutdown.
It's rather hard (if at all possible) to do a proper stack cleanup
on an unclean shutdown, so I'm just disabling it in this case.
nNumOfElements was incremented after the pDestructor code, so any
code in the dtor would get a wrong number of elements.
Right now the bucket deletion code is replicated in four places,
it should probably be moved off into one function (or rather,
zend_hash_apply_deleter should be used everywhere). The codes are
subtly different though in that the HANDLE_UNBLOCK_INTERRUPTIONS()
happens in different places. In particular it seems odd that in
some cases interruptions stay blocked during the destructor call.
If user inherits Exception and overrides the properties to arbitrary data types,
or simply doesn't run parent::__construct(), here we go. Just convert everything
to the appropriate data type, like Exception::__toString() does.
* PHP-5.5: (276 commits)
Patch for Bug #64544. The process title change module keeps track of the locally allocated environ, so it doesn't need to worry about when environ changes underneath it, for example by putenv()/setenv()
Fix "passing NULL to non-pointer argument" warnings in intl
Remove support for cloning generators
Removed deprecated check
Fix whitespace issue in the SOAP test
Fix SOAP test
Forgot to fix the test on 5.4
Exclude Travis build for 5.3 and 5.4
Fix tests after addition of ^ (xor) operator to ini
Fix Bug #64545: PHP Error in ef93a93ee2
Attempt to fix SKIP
This will PHP 5.3.25
Typo fix (greater then => greater than)
don't optimize script if it's not going to be cached
Reimplemented OPcache restart trigger. Now, if memory or hash are full the restart is scheduled only in case the amount of wasted memory is above opcache.max_wasted_percentage. Otherwise OPcahce continue serving the following requests using already cached files, but doesn't try to add new files (the cache is full anyway).
With pkgconfig < 0.28 output is a single space With pkgconfig = 0.28 output is an empty string, This breaks the test on the 2 vars
Fixed issue #78 (incorrect file path validation)
Fix test on Mac (\D shows up)
Add test for #64529
will be 5.4.15
...
PHP should preserve the least significant bits when casting from double
to long. Zend.m4 contains this:
AC_DEFINE([ZEND_DVAL_TO_LVAL_CAST_OK], 1, [Define if double cast to long preserves least significant bits])
If ZEND_DVAL_TO_LVAL_CAST_OK is not defined, zend_operators.h had an
inline implementation of zend_dval_to_lval() that would do a cast to an
int64_t (when sizeof(long) == 4), then a cast to unsigned long and
finally the cast to long.
While this works well for doubles inside the range of values of the type
used in the first cast (int64_t in the 32-bit version and unsigned long
in the 64-bit version), if outside the range, it is undefined behavior
that WILL give varying and not particularly useful results.
This commit uses fmod() to first put the double in a range that can
safely be cast to unsigned long and then casts this unsigned long to
long. This last cast is implementation defined, but it's very likely
that this gives the expected result (i.e. the internal 2's complement
representation is unchanged) on all platforms that PHP supports. In any
case, the previous implementationa already had this assumption.
This alternative code path is indeed significantly slower than simply
casting the double (almost an order of magnitude), but that should not
matter because casting doubles with a very high absolute value is a
rare event.
As we discussed with stefan, we think previous of allowing use with
classes is a bug, should be forbided, anyway, the error message should
be improved.
This also reverses the destruction order of the pushed arguments to
align with how it is done everywhere else.
I'm not exactly sure whether this is the right way to fix it, but it
seems to work fine.
Rule of thumb: Always implement the object clone handler rather
than the object storage clone handler. Actually I think we should
drop the latter. It's nearly never usable.
If a generator is destroyed in a finally block it will resume the generator to run that finally
block before freeing the generator. This was done in the object storage free handler.
Running user code in the free handler isn't safe though because the free handlers may be run
during request shutdown, already after several key components have been shut down.
This is avoided by doing the finally handling in the dtor handler. These handlers are run at the
start of the shutdown sequence.
* PHP-5.4:
fix bug #63462 (Magic methods called twice for unset protected properties)
NEWS for bug #64011. See 77ee200
Fix bug #64011 (get_html_translation_table())
Fix News
Update the arguments in the prototype of fpm_socket_unix_test_connect().
fixed build
NEWS for bug #63893
Fixed inconsequential bug in strtr()
Revert "Apply the fputcsv test fix to SplFileObject_fputcsv.phpt. Mea culpa."
Revert "Update fputcsv() to escape all characters equally."
Remove _GNU_SOURCE, add local heap sort
The compiler can figure this out
Remove unused block
strtr() with 2nd param array - optimization
Refactoring, bugs & leaks
Optimize strtr w/ 2nd arg array
Before making changes to the implementation of
ZEND_SIGNED_MULTIPLY_LONG(), add some test cases
to make sure the various implementations remain
equivalent.
* PHP-5.4:
fix bug #63982: isset() inconsistently produces a fatal error on protected property
different OSes have different messages, and that's not what the test is about anyway
Generator::throw($exception) throws an exception into the generator. The
exception is thrown at the current point of suspension within the generator.
It basically behaves as if the current yield statement were replaced with
a throw statement and the generator subsequently resumed.
If zend_generator_close is called from within zend_generator_resume (e.g.
due to a return statement) then all the EGs will still be using the values
from the generator. That's why the stack frame has to be the last thing
that is dtored, otherwise some other dtor that is using
EG(current_execute_data) might access the already freed memory segment.
This was the case with the closure dtor.
The fix is to move the dtors for key and value to the start of the handler.
This way the stack frame is the last thing that is freed.
When the return value of yield wasn't used it was leaked.
This is fixed by using a TMP_VAR return value instead of VAR. TMP_VARs are
automatically freed when they aren't used.
The code did not check whether the zend_hash_index_find calls succeded,
so PHP crashed when an array callback was called that contains two elements
which don't have the indices 0 and 1.
set_error_handler(null) and set_exception_handler(null) now return the
previous error/exception handler instead of just returning bool(true).
This is consistent with the behavior of these functions with non-null
values.
This allows the error handler to be reset using set_error_handler(null).
As the code suggests this behavior was already previously intended, but
the callback check was done too strictly.
This reverts the following two commits:
* 6ba2e662e4
* d8f8e98d8e
Laruence already did some partial changes to set_error_handler and
set_exception_handler. I'm reverting those modifications to apply the full
set of changes. (The modifications changed the code structure in a way that
would lead to more duplication with the new behavior.)
EG(arg_types_stack) is now also backed up when generators are used. This
allows the use of yield in nested method calls.
This commit adds two new functions to the zend_ptr_stack API:
zend_ptr_stack_push_from_memory
zend_ptr_stack_pop_into_memory
both taking the following arguments:
zend_ptr_stack *stack, int count, void **pointers
* generators: (70 commits)
Fix typos
Fix segfault when traversing a by-ref generator twice
Make sure that exception is thrown on rewind() after closing too
Remove implementation stubs for yield delegation
Fix several issues and allow rewind only at/before first yield
Run finally if generator is closed before finishing
Finally with return now works in generators too
Add dedicated opcode for returns from a generator
Disallow serialization and unserialization
Fix zts build (typo)
Drop Generator::close() method
Forgot to add test
Support trivial finally in generators (no yield, no return)
Fix implementation of Iterator interface
Add T_YIELD in tokenizer_data.c
Throw error also for return occuring before yield
Fix throwing of exceptions within a generator
Remove reference restrictions from foreach
Require parenthesis around yield expressions
Add some more tests
...
If you try to traverse an already closed generator an exception will now be
thrown.
Furthermore this changes the error for traversing a by-val generator by-ref
from an E_ERROR to an Exception.
* Trying to resume a generator while it is already running now throws a
fatal error.
* Trying to use yield in finally while the generator is being force-closed
(by GC) throws a fatal error.
* Rewinding after the first yield now throws an Exception
This is just an intial merge. It does not yet make generators and finally
work together.
Conflicts:
Zend/zend_language_scanner.c
Zend/zend_language_scanner_defs.h
Zend/zend_vm_def.h
Zend/zend_vm_execute.h
Zend/zend_vm_execute.skl
Zend/zend_vm_opcodes.h
It looks like you have to implement the Iterator interface *before*
assigning get_iterator. Otherwise the structure for user iterators isn't
correctly zeroed out.
Additionaly I'm setting class_entry->iterator_funcs.funcs now. Not sure if
this is strictly necessary, but better safe than sorry ;)
the reason why jpauli and I can not reproduce is (it's silly):
I typo "USE_ZEND_ALLOC *&&* valgrind" at the first time, then I always ctrl+r
and jpauli copied my command from the pastbin :)
thanks
Previously only an error was thrown when return occured after yield. Also
returns before the first yield would fail for by-ref generators.
Now the error message is handled in pass_two, so all returns are checked.
If a generator threw an exception and was iterated using foreach (i.e. not
manually) an infinite loop was triggered. The reason was that the exception
was not properly rethrown using zend_throw_exception_internal.