|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2018-05-14 05:12 UTC] ray dot ward at bigcommerce dot com
Description:
------------
We're experiencing occasional segfaults during php shutdown
php-fpm7.2[12494]: segfault at 0 ip 0000000000605e5b sp 00007fff78ece470 error 6 in php-fpm7.2[400000+35e000]
Unfortunately I don't have much to go on apart from a GDB trace:
Program received signal SIGSEGV, Segmentation fault.
gc_mark_grey (ref=0x0) at ./Zend/zend_gc.c:562
#0 gc_mark_grey (ref=0x0) at ./Zend/zend_gc.c:562
#1 0x0000000000606ce8 in gc_mark_roots () at ./Zend/zend_gc.c:583
#2 zend_gc_collect_cycles () at ./Zend/zend_gc.c:1057
#3 0x0000000000606921 in gc_possible_root (ref=0x0) at ./Zend/zend_gc.c:286
#4 0x00000000005cab18 in gc_check_possible_root (ref=<optimized out>) at ./Zend/zend_gc.h:158
#5 i_zval_ptr_dtor (zval_ptr=0x7f318cfb6320, zval_ptr=0x7f318cfb6320) at ./Zend/zend_variables.h:51
#6 _zval_ptr_dtor (zval_ptr=zval_ptr@entry=0x7f318cfb6320) at ./Zend/zend_execute_API.c:532
#7 0x00000000004e633c in spl_object_storage_dtor (element=<optimized out>) at ./ext/spl/spl_observer.c:153
#8 0x00000000005ee825 in zend_hash_destroy (ht=ht@entry=0x7f3211c7c640) at ./Zend/zend_hash.c:1234
#9 0x00000000004e630a in spl_SplObjectStorage_free_storage (object=0x7f3211c7c6a8) at ./ext/spl/spl_observer.c:112
#10 0x000000000061ba8b in zend_objects_store_free_object_storage (objects=0x0, objects@entry=0xa0e0b8 <executor_globals+824>, fast_shutdown=152 '\230', fast_shutdown@entry=1 '\001')
at ./Zend/zend_objects_API.c:105
#11 0x00000000005cb034 in shutdown_executor () at ./Zend/zend_execute_API.c:265
#12 0x00000000005dccbb in zend_deactivate () at ./Zend/zend.c:1036
#13 0x0000000000576e0a in php_request_shutdown (dummy=<optimized out>) at ./main/main.c:1904
#14 0x000000000042dd78 in main (argc=17133702, argv=0x1057043) at ./sapi/fpm/fpm/fpm_main.c:1994
_May_ be opcache related, disabling opcache eliminated the segfault.
We rely on complex shutdown functions. Perhaps an object being referenced in a function has been GC'd already?
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Thu Nov 06 17:00:01 2025 UTC |
Also seeing similar segfaults on the PHP 7.0 boxes we haven't upgraded #0 gc_mark_grey (ref=0x0) at ./Zend/zend_gc.c:521 #1 0x00000000005eabd8 in gc_mark_roots () at ./Zend/zend_gc.c:548 #2 zend_gc_collect_cycles () at ./Zend/zend_gc.c:1025 #3 0x00000000005d73bd in zif_gc_collect_cycles (execute_data=<optimized out>, return_value=0x7f44baa13240) at ./Zend/zend_builtin_functions.c:413 #4 0x0000000000646b1d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () at ./Zend/zend_vm_execute.h:714 #5 0x000000000060205b in execute_ex (ex=<optimized out>) at ./Zend/zend_vm_execute.h:414 #6 0x00000000005b21f5 in zend_call_function (fci=fci@entry=0x7ffc2eabe6e0, fci_cache=0x7f444687b340, fci_cache@entry=0x0) at ./Zend/zend_execute_API.c:867 #7 0x00000000005b2629 in call_user_function_ex (function_table=<optimized out>, object=object@entry=0x0, function_name=<optimized out>, retval_ptr=retval_ptr@entry=0x7ffc2eabe770, param_count=<optimized out>, params=<optimized out>, no_separation=1, symbol_table=0x0) at ./Zend/zend_execute_API.c:675 #8 0x00000000005b265d in call_user_function (function_table=<optimized out>, object=object@entry=0x0, function_name=<optimized out>, retval_ptr=retval_ptr@entry=0x7ffc2eabe770, param_count=<optimized out>, params=<optimized out>) at ./Zend/zend_execute_API.c:657 #9 0x00000000004feaf0 in user_shutdown_function_call (zv=<optimized out>) at ./ext/standard/basic_functions.c:4921 #10 0x00000000005d3a0c in zend_hash_apply (ht=0x7f44baa862a0, apply_func=apply_func@entry=0x4fea10 <user_shutdown_function_call>) at ./Zend/zend_hash.c:1537 #11 0x0000000000501f86 in php_call_shutdown_functions () at ./ext/standard/basic_functions.c:5005 #12 0x000000000055f9e5 in php_request_shutdown (dummy=<optimized out>) at ./main/main.c:1796 #13 0x0000000000444cf3 in main (argc=27158462, argv=0x19e6775) at ./sapi/fpm/fpm/fpm_main.c:1995The zbacktrace provided some insights. We have a shutdown function that is interacting with an object that itself calls gc_collect_cycles. (gdb) zbacktrace [0x7f44baa13260] gc_collect_cycles() [internal function] [0x7f44baa131e0] <redacted>\BatchIndexStrategy->flushUpdateQueue() [0x7f44baa13170] <redacted>\BatchIndexStrategy->flushQueues() [0x7f44baa13100] <redacted>\BatchIndexStrategy->cleanup() [0x7f44baa13030] {closure}() <redacted>:1903 [0x7ffc2eabe640] ??? The object queues updates to be sent to a 3rd party system and flushes them in batches when it reaches a preset size. We also invoke the flush on shutdown to push any remaining/pending updates. We use gc_collect_cycles() as an attempt to force GC and free up memory. Is calling gc_collect_cycles() from php code while php itself is shutting down and GC'ing a bad idea and could lead to these sorts of issues?