[php-src] PR #23362: Fix GH-10134: report internal call arguments to GC

Pull Request: https://github.com/php/php-src/pull/23362 Author: xhon-pelushi Fixes GH-10134. ## The bug A fiber can be suspended *below* an internal function. That leaves the internal frame parked on the fiber's stack with the arguments that were pushed for it still live — the frame owns them and only releases them when it returns. zend_unfinished_execution_gc_ex() returns early for internal frames without reporting those arguments: ```c if (!ZEND_USER_CODE(EX(func)->common.type)) { ZEND_ASSERT(...); return NULL; /* arguments never reported */ } ``` So the cycle collector never sees them, and any cycle running through such an argument is uncollectable — it is only broken at request shutdown. ## Not specific to generators GH-10134 reports this as a generator problem, because the reporter hit it through Fiber::suspend() inside a generator resumed by Generator::send($fiber) — $fiber lands in the argument slot of the internal Generator::send frame. But nothing about it is generator-specific. With no generator anywhere, a fiber suspended inside array_map() whose array argument holds the fiber behaves identically (second test added here). ## How it was diagnosed zend_fiber_object_gc() is not at fault — it correctly walks the suspended fiber's frames, finds the generator frame, and calls zend_generator_frame_gc() on it. Instrumenting the collector's root processing showed the actual failure: ``` [root-before] Fiber rc=2 PURPLE reported obj Fiber rc=2 <- reported once [root-after-mark] Fiber rc=1 GREY [root-after-mark] Generator rc=3 <- restored from 0 ``` The Fiber's refcount is 2 but the mark phase discovers only one of those references, so it lands at 1 instead of 0, gc_scan concludes it is externally referenced, and gc_scan_black restores every refcount it had decremented. Dumping the frames shows where the second reference lives: ``` frame ... INTERNAL func=send nargs=1 ARG[0] type=8 Fiber 0x... <- never reported ``` ## On double counting This was the main risk. It does not happen: on ZEND_DO_ICALL / ZEND_DO_FCALL the VM does EX(call) = call->prev_execute_data, so an *entered* frame is no longer in its caller's EX(call) chain and is therefore not also scanned by zend_unfinished_calls_gc(), which only walks calls that are still being built. Those pending frames are siblings rather than ancestors, so they never show up in the prev_execute_data walk either. zend_unfinished_execution_gc_ex() has two callers. zend_generator_frame_gc() always passes generator->execute_data, which is user code, so only the fiber path is affected in practice. ## Testing - Both new tests **fail on unmodified master and pass with this change** — I ran them against a pristine build to confirm they are real regression guards. - The issue's verbatim script now prints the expected order (Generator dtor, Fiber dtor, Shutdown) instead of Shutdown first, and gc_collect_cycles() returns 1 instead of 0. - **No premature frees**, which is the thing to worry about when handing GC additional edges: an object passed as an internal-frame argument that is *also* still referenced from live scope survives gc_collect_cycles() and remains usable. Checked explicitly. - Full test suite on this build (--disable-all --enable-debug): **13386 passed, 0 failed, 0 warned** (7 expected-fail, the rest skipped for disabled extensions). - Zend/tests/fibers and Zend/tests/gc under valgrind memcheck: clean. Built and tested on Linux x86_64, --disable-all --enable-debug, so the extension-heavy parts of the suite were skipped; a normal CI run would cover those.