Otherwise the assignment will have the same number as the default arm
which will 1. mis-trigger a breakpoint and 2. mark the line as covered
even when it isn't.
Closes GH-6083
When using zpp 'f' or Z_PARAM_FUNC, if the fcc points to a call
trampoline release it immediately and force zend_call_function
to refetch it. This may require additional callability checks
if __call is used, but avoids the need to carefully free fcc
values in all internal functions -- in some cases this is not
simple, as a type error might be triggered by a later argument
in the same zpp call.
This fixes oss-fuzz #25390.
Closes GH-6073.
For php-ast interning the file name is an effective memory leak,
see php-ast#134.
I don't think there's any reason to do this. At some point this
was needed due to bugs in the interned string mechanism that
caused issues if the string was later interned, e.g. through a
__FILE__ reference. These issues have since been resolved.
In conjunction with the filenames_table removal in c4016ecd44
this means that filenames now need to be refcounted like normal
strings. In particular the filename reference in op_arrays and CEs
are refcounted.
Applying the obvious fix ... however, I think we may need to
rething how we handle trampoline fcc for "f" zpp. It might make
sense to use fcc->function_handler == NULL for that case and
force it to be fetched in zend_call_function instead (it will
be reset to that after the call anyway). Otherwise we will keep
chasing these leaks, as it's the only instance where it's
necessary to free a zpp result.
Do not decrement the refcount before allocating the new string,
as the allocation operation may bail out and cause a use-after-free
lateron. We can only decrement the refcount once the allocation
has succeeded.
Fixes oss-fuzz #25384.
Based on:
"Fast CRC Computation for Generic Polynomials Using PCLMULQDQ Instruction"
V. Gopal, E. Ozturk, et al., 2009, http://intel.ly/2ySEwL0
Signed-off-by: Frank Du <frank.du@intel.com>
Closes GH-6018
Use the general zend_generator_throw_exception() helper for this.
Otherwise we don't handle the off-by-one opline correctly (should
we maybe just stop doing that?)
This is a followup to ad750c3bb6,
which fixed a different yield from exception handling problem that
happened to show up in the same test case from oss-fuzz #25321.
Now both issues should be fixed.
Shift the responsibility for emitting MAKE_REF to the list assignment
code, to make sure that LIST_W and MAKE_REF are directly adjacent,
and there are no opcodes in between that could modify the LIST_W
result.
Additionally, adjust the zend_wrong_string_offset() code to not
perform a loop over opcodes and assert that the next opcode is
a relevant one. The VM write-safety model requires this.
This is a followup to a07c1f56aa
and the full fix for oss-fuzz #25352.
There is a deeper underlying issue here, in that the opcodes violate
VM write-fetch safety, but let's fix the infinite loop first.
This fixes oss-fuzz #25352.
This can happen if zend_call_function inserted a dummy frame,
and we already switched to the dummy frame in leave_helper,
and an exception is thrown during CV destruction.
Fixes oss-fuzz #25343.
FE_RESET sets the result to UNDEF in this case. We should infer
some type here, because no type generally implies unreachable
code. In this case SCCP ended up replacing the FE_RESET result
with null, including in FE_FREE.
We can't just remove the uses, we need to replace uses.
The test case only fails on master with SSA integrity violations,
but I believe the root issue also existed previously.
