Bug #69464 [Fbk->Csd]: Segfault in zend_hash_destroy() during shutdown

From: Date: Mon, 20 Apr 2015 14:09:52 +0000
Subject: Bug #69464 [Fbk->Csd]: Segfault in zend_hash_destroy() during shutdown
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-192241@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=69464&edit=1 ID: 69464 Updated by: dmitry@php.net Reported by: berdir@php.net Summary: Segfault in zend_hash_destroy() during shutdown -Status: Feedback +Status: Closed Type: Bug Package: Scripting Engine problem Operating System: Linux PHP Version: master-Git-2015-04-15 (Git) Assigned To: dmitry Block user comment: N Private report: N New Comment: The GC bug is fixed. Previous Comments: ------------------------------------------------------------------------ [2015-04-19 21:51:35] berdir@php.net I've opened https://bugs.php.net/bug.php?id=69484 for the opcache related errors. I've also had another segfault that I reported there as well, as it happened in the same test and might be related. ------------------------------------------------------------------------ [2015-04-18 07:20:46] berdir@php.net Yes, the installer works again! I have some new issues, though... In certain places, I get zend_mm_heap corrupted errors in the apache logs and empty responses. For example at /aggregator/sources/add (after enabling the aggregator module with drush en -y aggregator or on /admin/modules. What's weird is that they go away when I disable opcache. I also got another segfault, but I wasn't able to identify when exactly that happened: Program terminated with signal SIGSEGV, Segmentation fault. #0 i_free_compiled_variables (execute_data=<optimized out>) at /home/berdir/tools/php-src/Zend/zend_execute.c:1810 1810 if (!Z_DELREF_P(cv)) { (gdb) bt #0 i_free_compiled_variables (execute_data=<optimized out>) at /home/berdir/tools/php-src/Zend/zend_execute.c:1810 #1 zend_leave_helper_SPEC () at /home/berdir/tools/php-src/Zend/zend_vm_execute.h:445 #2 0x00007f870e6957bb in execute_ex (ex=<optimized out>) at /home/berdir/tools/php-src/Zend/zend_vm_execute.h:394 #3 0x00007f870e64674e in zend_call_function (fci=fci@entry=0x7fffc29b51d0, fci_cache=<optimized out>, fci_cache@entry=0x7fffc29b51a0) at /home/berdir/tools/php-src/Zend/zend_execute_API.c:840 #4 0x00007f870e575d71 in zif_call_user_func_array (execute_data=0x7f8704e13520, return_value=0x7f8704e13510) at /home/berdir/tools/php-src/ext/standard/basic_functions.c:4787 #5 0x00007f870e6eaa2d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () at /home/berdir/tools/php-src/Zend/zend_vm_execute.h:691 #6 0x00007f870e6957bb in execute_ex (ex=<optimized out>) at /home/berdir/tools/php-src/Zend/zend_vm_execute.h:394 #7 0x00007f870e64674e in zend_call_function (fci=fci@entry=0x7fffc29b5410, fci_cache=<optimized out>, fci_cache@entry=0x7fffc29b53e0) at /home/berdir/tools/php-src/Zend/zend_execute_API.c:840 #8 0x00007f870e575d71 in zif_call_user_func_array (execute_data=0x7f8704e12150, return_value=0x7f8704e11fe0) at /home/berdir/tools/php-src/ext/standard/basic_functions.c:4787 #9 0x00007f870e6eaa2d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER () at /home/berdir/tools/php-src/Zend/zend_vm_execute.h:691 #10 0x00007f870e6957bb in execute_ex (ex=<optimized out>) at /home/berdir/tools/php-src/Zend/zend_vm_execute.h:394 #11 0x00007f870e655b15 in zend_execute_scripts (type=8, retval=0x10, retval@entry=0x0, file_count=3) at /home/berdir/tools/php-src/Zend/zend.c:1398 #12 0x00007f870e5f8600 in php_execute_script (primary_file=primary_file@entry=0x7fffc29b7940) at /home/berdir/tools/php-src/main/main.c:2468 #13 0x00007f870e6ef68a in php_handler (r=<optimized out>) at /home/berdir/tools/php-src/sapi/apache2handler/sapi_apache2.c:673 #14 0x00007f8712f4ceb0 in ap_run_handler () #15 0x00007f8712f4d3f9 in ap_invoke_handler () #16 0x00007f8712f62bac in ap_internal_redirect () I have no idea if they are related, feel free to just close this bug report if you think not, I'll open new issues when I do more testing next week. ------------------------------------------------------------------------ [2015-04-17 15:41:27] dmitry@php.net I hope I fixed the GC problem. At least I can't reproduce it any more. Could you please retest. ------------------------------------------------------------------------ [2015-04-17 00:33:49] dmitry@php.net I fixed two problems triggered by Drupal-8, however I see at least one unfixed GC related problem. It may be reproduced with simple script. The problem must be visible with valgrind. <?php class A { public $a; public $x; function __destruct() { unset($this->x); } } $a = new A; $a->a = $a; $a->x = []; $a->x[] =& $a->x; $a->x[] = $a; var_dump($a); var_dump(gc_collect_cycles()); unset($a); var_dump(gc_collect_cycles()); var_dump(gc_collect_cycles()); ?> The problem that __destructor() breaks the garbage graph, and it's destroyed only partially, and the remaining part still keeps references to deallocated data. ------------------------------------------------------------------------ [2015-04-16 09:29:14] dmitry@php.net this doesn't work for me. I followed your instruction + made composer update. Anyway, I get a error (that I expect), but not any memory corruptions. Error: Cannot use Drupal\Component\Utility\String as String because 'String' is a special class name in ... I probably need some branch of drupal adopted for PHP7. Also, do you use any external extension (e.g. xdebug)? ------------------------------------------------------------------------ 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=69464 -- Edit this bug report at https://bugs.php.net/bug.php?id=69464&edit=1

« previous php.bugs (#192241) next »