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
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
The destructor of generators is a no-op when the generator is running in a fiber,
because the fiber may resume the generator. Normally the destructor
is not called in this case, but this can happen during shutdown.
We detect that a generator is running in a fiber with the
ZEND_GENERATOR_IN_FIBER flag.
This change fixes two cases not handled by this mechanism:
- The ZEND_GENERATOR_IN_FIBER flag was not added when resuming a "yield from $nonGenerator"
- When a generator that is running in a fiber has multiple children (aka multiple generators yielding from it), all of them could be considered to also run in a fiber (only one actually is), and could leak if not destroyed before shutdown.
Generators that suspended a fiber should not be dtor because they will be
executed during the fiber dtor.
Fiber dtor throws an exception in the fiber's context in order to unwind and
execute finally blocks, which will also properly dtor the generator.
Fixes GH-9916
Object handlers being separate from class entries is a legacy inherited from PHP 5. Today it has little benefit to keep them separate: in fact, accessing object handlers usually requires not-so-safe hacks.
While it is possible to swap handlers in a custom installed create_object handler, this mostly is tedious, as well as it requires allocating the object handlers struct at runtime, possibly caching it etc..
This allows extensions, which intend to observe other classes to install their own class handlers.
The life cycle of internal classes may now be simply observed by swapping the class handlers in post_startup stage.
The life cycle of userland classes may be observed by iterating over the new classes in zend_compile_file and zend_compile_string and then swapping their handlers.
In general, this would also be a first step in directly tying the object handlers to classes. Especially given that I am not aware of any case where the object handlers would be different between various instances of a given class.
Signed-off-by: Bob Weinand <bobwei9@hotmail.com>
