Bug #76339 [Opn]: segfault during shutdown

From: Date: Tue, 22 May 2018 09:41:28 +0000
Subject: Bug #76339 [Opn]: segfault during shutdown
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-215328@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=76339&edit=1 ID: 76339 Updated by: nikic@php.net 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: What stands out from your last traces is the vgMemCheck___builtin_vec_delete call, which indicates that something is trying to C++ delete[] a string allocated by PHP, which should definitely not be happening. From your extension list, the only one I know to use C++ is intl. Previous Comments: ------------------------------------------------------------------------ [2018-05-22 07:28:19] ray dot ward at bigcommerce dot com 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. ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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

« previous php.bugs (#215328) next »