Fix GH-10496: Segfault in fiber with nested calls

[bwoebi]

Skip the current executing call in fibers, see analysis: #10496 (comment)

[arnaud-lb]

Thank you!

I think that the root cause is the - 1 here:

php-src/Zend/zend_execute.c

Lines 4498 to 4500 in 8c8a38a

	/* -1 required because we want the last run opcode, not the next to-be-run one. */
	uint32_t op_num = execute_data->opline - op_array->opcodes - 1;
	zend_unfinished_calls_gc(execute_data, call, op_num, gc_buffer);

I borrowed that from zend_generator.c, but this is only applicable when the frame was suspended by yield. These frames suspended will have EX(opline) pointing to the next opline after yield. Otherwise, EX(opline) points to the opline that was executing when the suspension happened.

In gh10496.phpt, in the Fiber's root frame, EX(opline) is the ZEND_DO_UCALL for suspend(1). EX(opline)-1 is the ZEND_SEND_VAL for the literal 1. This leads zend_unfinished_calls_gc to believe that one argument was pushed to EX(call) (which is the call for ord()).

We should use execute_data->opline - 1 only for suspended generator frames.

WDYT?

I think that we can add a new parameter to zend_unfinished_execution_gc because it was only introduced in the last minor release.

[bwoebi]

In the past I've always been reminded about ABI when I wanted to change something after a release; if you say you can change it, then go ahead, but I won't :-D

And yes, you might be right with the -1, I hadn't considered that.

[bwoebi]

Closing as superseded by #10557.