Bug #76339 [Com]: segfault during shutdown

Edit report at https://bugs.php.net/bug.php?id=76339&edit=1 ID: 76339 Comment by: ray dot ward at bigcommerce dot com Reported by: ray dot ward at bigcommerce dot com Summary: segfault during shutdown Status: Open Type: Bug Package: opcache Operating System: Debian 8.10 PHP Version: 7.2.5 Block user comment: N Private report: N New Comment: I think that these implode/malloc reads are irrelevant to my issue as we get them whether the request segfaults or not. I think it's something more related to garbage collection or opcache. Looking at xdebug traces, I can confirm that the request completely finishes processing, and then it segfaults. We also don't get the complete output sent when this occurs, I presume there's still content in the output buffer that hasn't been flushed. Previous Comments: ------------------------------------------------------------------------ [2018-05-21 00:07:58] ray dot ward at bigcommerce dot com Although there are still other instances without any preg_replace ==22467== Invalid read of size 16 ==22467== at 0x40A9B4D: ??? ==22467== by 0x1C47C667: ??? ==22467== by 0x1C47C667: ??? ==22467== by 0x1C47C6C5: ??? ==22467== by 0xFFEFFC6DF: ??? ==22467== by 0x38072BCF: vgMemCheck___builtin_vec_delete (mc_malloc_wrappers.c:508) ==22467== Address 0x1c47c6c0 is 112 bytes inside a block of size 124 alloc'd ==22467== at 0x4C28C20: malloc (vg_replace_malloc.c:296) ==22467== by 0x5B1148: __zend_malloc (in /usr/sbin/php-fpm7.2) ==22467== by 0x53F3FC: php_implode (in /usr/sbin/php-fpm7.2) ==22467== by 0x53F745: zif_implode (in /usr/sbin/php-fpm7.2) ==22467== by 0x68A77B: execute_ex (in /usr/sbin/php-fpm7.2) ==22467== by 0x690015: zend_execute (in /usr/sbin/php-fpm7.2) ==22467== by 0x5DD012: zend_execute_scripts (in /usr/sbin/php-fpm7.2) ==22467== by 0x578337: php_execute_script (in /usr/sbin/php-fpm7.2) ==22467== by 0x42DD07: main (in /usr/sbin/php-fpm7.2) ==22467== ------------------------------------------------------------------------ [2018-05-21 00:01:57] ray dot ward at bigcommerce dot com I disabled the newrelic extension as it seems to mess with the traces (though itself not responsible for the problems). Here's an extract from a valgrind with ZEND_DONT_UNLOAD_MODULES=1 and USE_ZEND_ALLOC=0: ==22467== Invalid read of size 16 ==22467== at 0x40A9B4D: ??? ==22467== by 0x1D856F37: ??? ==22467== by 0x1D856F37: ??? ==22467== by 0x1D856F60: ??? ==22467== by 0xFFEFFC1AF: ??? ==22467== by 0x38072BCF: vgMemCheck___builtin_vec_delete (mc_malloc_wrappers.c:508) ==22467== Address 0x1d856f60 is 64 bytes inside a block of size 67 alloc'd ==22467== at 0x4C28C20: malloc (vg_replace_malloc.c:296) ==22467== by 0x5B1148: __zend_malloc (in /usr/sbin/php-fpm7.2) ==22467== by 0x53F3FC: php_implode (in /usr/sbin/php-fpm7.2) ==22467== by 0x53F745: zif_implode (in /usr/sbin/php-fpm7.2) ==22467== by 0x68A77B: execute_ex (in /usr/sbin/php-fpm7.2) ==22467== by 0x5CC6BB: zend_call_function (in /usr/sbin/php-fpm7.2) ==22467== by 0x474003: php_pcre_replace_func_impl (in /usr/sbin/php-fpm7.2) ==22467== by 0x475381: php_replace_in_subject_func (in /usr/sbin/php-fpm7.2) ==22467== by 0x4755EE: preg_replace_func_impl (in /usr/sbin/php-fpm7.2) ==22467== by 0x475BD1: zif_preg_replace_callback (in /usr/sbin/php-fpm7.2) ==22467== by 0x68E968: execute_ex (in /usr/sbin/php-fpm7.2) ==22467== by 0x690015: zend_execute (in /usr/sbin/php-fpm7.2) Seems to implicate something calling preg_replace_callback or preg_replace_callback_array. ------------------------------------------------------------------------ [2018-05-20 23:12:16] ray dot ward at bigcommerce dot com We've upgraded to APCu 5.1.11 and still experiencing the segfaults. We don't use any of the APC iterators, we actually have some old code using apc functions (fetch, store, delete) with the apcu_bc extension (v1.0.4). I'll have a dig and see if we're doing anything dodgy with implode() ------------------------------------------------------------------------ [2018-05-20 15:53:18] nikic@php.net Sorry, didn't see the reply here. If that's really APCu 5.1.8 and not some heavily backported version, I'd definitely recommend updating that to see if it resolves the issue. Especially if you are using APCIterator / APCuIterator anywhere in your codebase. deb.sury has a current 5.1.11 release. Unfortunately the part that performs the out of bounds reads is not visible in the valgrind trace. It might help to specify ZEND_DONT_UNLOAD_MODULES=1 in addition to USE_ZEND_ALLOC=0 to preserve symbols from DSOs here. @rasmus: The invalid read doesn't occur inside implode(), but rather at whichever point the string generated by implode() is used. ------------------------------------------------------------------------ [2018-05-20 15:23:38] rasmus@php.net ==25407== Invalid read of size 16 ... ==25407== Address 0x1c0e9090 is 112 bytes inside a block of size 124 alloc'd ==25407== at 0x4C28C20: malloc (vg_replace_malloc.c:296) ==25407== by 0x5B1148: __zend_malloc (in /usr/sbin/php-fpm7.2) ==25407== by 0x53F3FC: php_implode (in /usr/sbin/php-fpm7.2) ==25407== by 0x53F745: zif_implode (in /usr/sbin/php-fpm7.2) That says you have an implode() call that is reading off the end of the malloc'ed memory there, so I think you are reproducing the problem, it just isn't segfaulting under Valgrind. Any guesses as to what you are calling implode() on there? Any chance it could be an array that came out of APCu? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=76339 -- Edit this bug report at https://bugs.php.net/bug.php?id=76339&edit=1