|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2021-08-24 14:42 UTC] f dot sowade at r9e dot de
Description: ------------ I built PHP 8.0.9 as an Apache 2 module with the opcache and with the zend-test extensions: ./configure --disable-all --enable-zend-test --with-apxs2 --enable-zts --enable-opcache I then used the following php.ini which uses the zend-test extension to register an observer: zend_extension=opcache.so zend_test.observer.enabled=1 And I used a test script which just calls phpinfo(); The script works as expected after starting Apache. But when reloading Apache (systemctl reload apache2.service) I get a segmentation fault when accessing the script. This is the corresponding line from Apache's error.log: [Tue Aug 24 16:31:24.739107 2021] [core:notice] [pid 258215:tid 140253313567808] AH00051: child pid 258527 exit signal Segmentation fault (11), possible coredump in /etc/apache2 When restarting Apache (systemctl restart apache2.service) the script works again as expected. The problem also occurs with a custom PHP extension which uses the observer API. But since I was able to reproduce it with the zend-test extension, I thought that it was the easiest reproduction case. The problem does not occur if I don't load the opcache extension. Test script: --------------- <?php phpinfo(); PatchesPull Requests
Pull requests:
HistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Wed Mar 12 15:01:30 2025 UTC |
Joe investigated this some more and had the following comments, specifically this seems to be only triggered by Observer but the root cause is something in Opcache. As such I am going to re-assign this to you, Dmitry. Hope that is alright :-) > here's what is happening ... after reload, result.num of INIT_FCALL (which is cache slot num) is 0, and so occupies the same slot as the observer data, INIT_FCALL is fetching observer data and trying to execute it as fbc ... not quite sure why yet ... cache_size before reload is 16, after is 8. I've watched cache size (in persistent script) until process is destroyed and it has not changed, something in-between the process being destroyed and recreated (which I cannot find a way to debug) is doing something bad to cache_size ... I'm sure dmitry is going to see what is happening but I don't ... I'll attach a debug session from him: krakjoe@Fiji:/opt/src/php-src$ sudo service apache2 restart krakjoe@Fiji:/opt/src/php-src$ ps aux | grep apache2 www-data 330780 0.0 0.0 2144832 7236 ? Sl 15:21 0:00 /usr/sbin/apache2 -k start krakjoe@Fiji:/opt/src/php-src$ sudo gdb -p 330780 -- SNIPPED -- (gdb) break zend_accel_load_script Breakpoint 1 at 0x7f30928ca6ae: file /opt/src/php-src/ext/opcache/zend_accelerator_util_funcs.c, line 229. (gdb) c Continuing. [Switching to Thread 0x7f309130e640 (LWP 330782)] Thread 2 "apache2" hit Breakpoint 1, zend_accel_load_script (persistent_script=0x41edf380, from_shared_memory=32560) at /opt/src/php-src/ext/opcache/zend_accelerator_util_funcs.c:229 229 { (gdb) n 232 op_array = (zend_op_array *) emalloc(sizeof(zend_op_array)); (gdb) 233 *op_array = persistent_script->script.main_op_array; (gdb) 235 if (zend_hash_num_elements(&persistent_script->script.function_table) > 0) { (gdb) p op_array.cache_size $1 = 16 (gdb) q A debugging session is active. Inferior 1 [process 330780] will be detached. Quit anyway? (y or n) y Detaching from program: target:/usr/sbin/apache2, process 330780 [Inferior 1 (process 330780) detached] krakjoe@Fiji:/opt/src/php-src$ sudo service apache2 reload krakjoe@Fiji:/opt/src/php-src$ ps aux | grep apache2 www-data 330869 0.0 0.0 2145004 7408 ? Sl 15:22 0:00 /usr/sbin/apache2 -k start krakjoe@Fiji:/opt/src/php-src$ sudo gdb -p 330869 -- SNIPPED -- (gdb) break zend_accel_load_script Breakpoint 1 at 0x7f30928ca6ae: file /opt/src/php-src/ext/opcache/zend_accelerator_util_funcs.c, line 229. (gdb) c Continuing. [Switching to Thread 0x7f3090ffe640 (LWP 330871)] Thread 2 "apache2" hit Breakpoint 1, zend_accel_load_script (persistent_script=0x42299380, from_shared_memory=32560) at /opt/src/php-src/ext/opcache/zend_accelerator_util_funcs.c:229 229 { (gdb) n 232 op_array = (zend_op_array *) emalloc(sizeof(zend_op_array)); (gdb) 233 *op_array = persistent_script->script.main_op_array; (gdb) 235 if (zend_hash_num_elements(&persistent_script->script.function_table) > 0) { (gdb) p op_array.cache_size $1 = 8And a first attempt at a patch: diff --git a/Zend/zend_extensions.c b/Zend/zend_extensions.c index 4d4b1ffe09..adf9c57785 100644 --- a/Zend/zend_extensions.c +++ b/Zend/zend_extensions.c @@ -207,7 +207,7 @@ void zend_startup_extensions_mechanism() { /* Startup extensions mechanism */ zend_llist_init(&zend_extensions, sizeof(zend_extension), (void (*)(void *)) zend_extension_dtor, 1); - zend_op_array_extension_handles = 0; + //zend_op_array_extension_handles = 0; last_resource_number = 0; }