* Emit EXT_STMT after each pipe stage, and attach the TMP var that holds the intermediary result
* Add ZEND_EXT_STMT to keeps_op1_alive as per review
* Fix leak with EXT_STMT when pipe result is unused
Co-authored-by: Ilija Tovilo <ilija.tovilo@me.com>
On some systems, like Alpine, the thread stack size is small by default.
The last step of SSA construction involves variable renaming that is
recursive, and also makes copies of their version of the renamed
variables on the stack. This combination causes a stack overflow during
compilation on Alpine. Triggerable for example with very long match
statements.
A stop-gap solution would be to use heap allocated arrays for the
renamed variable list, but that would only delay the error as increasing
the number of match arms increases the depth of the dominator tree, and
will eventually run into the same issue.
This patch transforms the algorithm into an iterative one.
There are two states stored in a worklist stack: positive numbers
indicate that the block still needs to undergo variable renaming.
Negative numbers indicate that the block and its dominated children are
already renamed. Because 0 is also a valid block number, we bias the
block numbers by adding 1.
To restore to the right variant when backtracking the "recursive" step,
we index into an array pointing to the different variable renaming
variants.
Closes GH-19083.
8MB sounded a prudent size for older 10.9 macOs release, however
with newer mac with arm64, it triggers a stack overflow.
Cherry picks b320aabc5e (GH-13319) from PHP-8.4.
Closes GH-19390.
Reuse the helper zend_foreach_op_array() that we move to the
zend_optimizer.h header to be usable in opcache.
Note that applying this to other op_array loops is not easy because they either:
- start from EG(persistent_classes_count)
- or only apply to classes
Since GH-13188 we're no longer immediately updating iterator positions when
deleting array elements. zend_hash_rehash() needs to adapt accordingly by
adjusting nInternalPosition for IS_UNDEF elements. This is already the case for
array iterators.
Fixes GH-19280
Closes GH-19323
Generator::throw() on a running generator is not allowed. It throws "Cannot
resume an already running generator" when trying to resume the generator to
handle the provided exception.
However, when calling Generator::throw() on a generator with a non-Generator
delegate, we release the delegate regardless. If a Fiber was suspended in
the delegate, this causes use after frees when the Fiber is resumed.
Fix this by throwing "Cannot resume an already running generator" earlier.
Fixes GH-19326
Closes GH-19327
Since GH-17755 self and parent are compile-time resolved. We may now also
encounter this type error at runtime outside of the class itself.
Fixes GH-19304
Normally we prevent generators from being resumed while they are already
running, but we failed to do so for generators delegating to non-Generators. As
a result such generator can be resumed, terminated, which causes unexpected
results (crashes) later.
In gh19306.phpt in particular, the generator delegate It::getIterator() suspends
while being called by generator g(). We then resume g(), which throws while
trying to resume It::getIterator(). This causes g() and It::getIterator()
to be released. We then UAF when resuming the Fiber in It::getIterator().
Fix this by ensuring that generators are marked as running while they fetch
the next value from the delegate.
Fixes GH-19306
Closes GH-19315