We assume that non-running generators have their ->execute_data->opline pointing to the opline next to the yield or yield from that stopped it (e.g. here, here, and here).

However, when fetching the next delegated value for a yield from $nonGenerator, the opline points to the yield from op due to temporary adjustments in zend_generator_get_next_delegated_value().

This causes crashes when cleaning up unfinished calls or assertion failures during GC.

Here I change zend_generator_get_next_delegated_value() to not adjust the opline, so that the expectation is always true.

zend_generator_throw_exception() also adjusts the opline, which causes similar issues if zval_ptr_dtor(&generator->values) triggers the GC. I update it to cancel the adjustment before destroying generator->values.

Alternatively, I think it may be simpler to stop incrementing opline in the yield and yield from op handlers (and to leave this task to zend_generator_resume()), so that we don't have to patch opline in other places. However this targets 8.2, so I didn't explore this idea.

While testing I've also found that calling ->throw() on a running generator, or a child of a running generator, may crash. In [1], the getIterator() generator is getting closed during ->throw(), but its execute_data is accessed after that. In [2] we break zend_generator_throw_exception()'s assumption of being called on a non-running generator. Should we forbid calling ->throw() when zend_generator_get_current() is running?