Segfault when using ReflectionFiber

[danog]

Description

The following code: https://paste.daniil.it/segfault_reflectionfiber.tar.xz, a.php (a slightly modified version of revolt that registers all created fibers into a WeakMap for logging)

Resulted in this output:

~/amp $ php a.php
string(17) "Running fibers: 7"
Segmentation fault

But I expected this output instead: No segfault

PHP Version

PHP 8.2.1 and a dev build of 6838145

Operating System

Arch linux

[nielsdos]

I can reproduce this.
First has an invalid read and then a near-nullptr access (line numbers are from PHP-8.2):

string(17) "Running fibers: 7"
==176150== Invalid read of size 8
==176150==    at 0x563F73: zim_ReflectionFiber_getExecutingFile (php_reflection.c:7102)
==176150==    by 0x7D8B58: ZEND_DO_FCALL_SPEC_RETVAL_USED_HANDLER (zend_vm_execute.h:1951)
==176150==    by 0x84ED27: execute_ex (zend_vm_execute.h:56056)
==176150==    by 0x77A682: zend_call_function (zend_execute_API.c:930)
==176150==    by 0x89E8BB: zend_fiber_execute (zend_fibers.c:504)
==176150==    by 0x89E197: zend_fiber_trampoline (zend_fibers.c:299)
==176150==    by 0x6E85FE: make_fcontext (make_x86_64_sysv_elf_gas.S:78)
==176150==  Address 0x71f3248 is 16 bytes after a block of size 136 alloc'd
==176150==    at 0x4841888: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==176150==    by 0x7A0E1B: zend_register_functions (zend_API.c:2811)
==176150==    by 0x7A2198: do_register_internal_class (zend_API.c:3181)
==176150==    by 0x7A2460: zend_register_internal_class (zend_API.c:3245)
==176150==    by 0x7A22B3: zend_register_internal_class_ex (zend_API.c:3208)
==176150==    by 0x89D893: register_class_Fiber (zend_fibers_arginfo.h:81)
==176150==    by 0x8A07BA: zend_register_fiber_ce (zend_fibers.c:931)
==176150==    by 0x88B244: zend_register_default_classes (zend_default_classes.c:42)
==176150==    by 0x7B7165: zm_startup_core (zend_builtin_functions.c:38)
==176150==    by 0x79EA13: zend_startup_module_ex (zend_API.c:2235)
==176150==    by 0x79EA71: zend_startup_module_zval (zend_API.c:2250)
==176150==    by 0x7B0E1E: zend_hash_apply (zend_hash.c:2015)
==176150== 
==176150== Invalid read of size 4
==176150==    at 0x563F8D: zim_ReflectionFiber_getExecutingFile (php_reflection.c:7102)
==176150==    by 0x7D8B58: ZEND_DO_FCALL_SPEC_RETVAL_USED_HANDLER (zend_vm_execute.h:1951)
==176150==    by 0x84ED27: execute_ex (zend_vm_execute.h:56056)
==176150==    by 0x77A682: zend_call_function (zend_execute_API.c:930)
==176150==    by 0x89E8BB: zend_fiber_execute (zend_fibers.c:504)
==176150==    by 0x89E197: zend_fiber_trampoline (zend_fibers.c:299)
==176150==    by 0x6E85FE: make_fcontext (make_x86_64_sysv_elf_gas.S:78)
==176150==  Address 0x4 is not stack'd, malloc'd or (recently) free'd

Fiber status is "suspended", and it's the filename pointer which is NULL.
opline seems to point to garbage too (value of opcode changes everytime I print it out, and it gets values that it shouldn't be able to get, same with line number)

[bwoebi]

Without looking into the crash itself, a block of size 136 is a zend_internal_function.
The current code:

		prev_execute_data = fiber->execute_data->prev_execute_data;
	RETURN_STR_COPY(prev_execute_data->func->op_array.filename);

Seems to assume that the caller of Fiber::suspend() is userland code, which seems like an invalid assumption, judging by the existence of that valgrind trace.

So, missing handling for unwinding internal functions (or returning empty string or such?).

[bwoebi]

The most trivial reproducer for this is:

namespace test;
$f = new \Fiber(fn() => call_user_func(["Fiber", "suspend"]));
$f->start();
var_dump((new \ReflectionFiber($f))->getExecutingFile());

Bonus points for no previous frame at all:

$f = new Fiber(Fiber::suspend(...));
$f->start();
var_dump((new ReflectionFiber($f))->getExecutingFile());