|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2015-01-09 09:35 UTC] bwoebi@php.net
-Status: Open
+Status: Assigned
-Assigned To:
+Assigned To: nikic
[2015-01-09 16:59 UTC] nikic@php.net
[2015-01-09 16:59 UTC] nikic@php.net
-Status: Assigned
+Status: Closed
[2016-07-20 11:40 UTC] davey@php.net
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Tue Oct 28 00:00:02 2025 UTC |
Description: ------------ Variants of that code (dependent on where execute_data->prev_execute_data is first needed) may also crash. My longer analysis resumed: EG(vm_stack_top) is reset to generator->stack->top in the next resume after zend_vm_stack_push_call_frame was called in the ZEND_INIT_FCALL_BY_NAME, that stack frame is now equal to EG(vm_stack_top), which is then returned in the next stack frame allocation (the var_dump one in the example) and prev_execute_data is set there to the address of the stack frame itself. Adding generator->stack->top = EG(vm_stack_top); on line 330 of zend_generators.c fixed the bug for me, but not sure if that's safe... Test script: --------------- function a($x) { var_dump($x); } function gen() { a(yield); } $g = gen(); $g->send(1); Expected result: ---------------- int(1) Actual result: -------------- Infinite loop: execute_data->prev_execute_data == execute_data