Bug #65590 [Com]: Apache segfaults and reports zend_mm_heap corrupted

Edit report at https://bugs.php.net/bug.php?id=65590&edit=1 ID: 65590 Comment by: phofstetter at sensational dot ch Reported by: ole dot skudsvik at gmail dot com Summary: Apache segfaults and reports zend_mm_heap corrupted Status: Open Type: Bug Package: opcache Operating System: Linux, CentOS 6 PHP Version: 5.4.19 Block user comment: N Private report: N New Comment: Reproducing this is actually quite easy: Just run any script with FPM and enabled opcache while constantly touching it in order to fill up opcache. Once oom_restarts increments (so opcache tries to restart itself due to having used up all memory), FPM will start crashing and it will continue to do so until you restart it completely. For us, opcache.fast_shutdown solves the problem completely. Previous Comments: ------------------------------------------------------------------------ [2015-05-15 09:23:24] nax_hh at hotmail dot com I was able to reproduce this in php 5.6 with a bit of difficulty # cat /etc/centos-release CentOS release 6.6 (Final) # php -v PHP 5.6.8 (cli) (built: Apr 16 2015 20:00:59) Copyright (c) 1997-2015 The PHP Group Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2015, by Zend Technologies script: opcache_reset(); require_once __DIR__.'/../vendor/autoload.php'; # composer $app = require_once __DIR__.'/../src/App.php'; # silex app $app->run(); error.log: zend_mm_heap corrupted zend_mm_heap corrupted zend_mm_heap corrupted zend_mm_heap corrupted zend_mm_heap corrupted ... I normally get only that error. If I launch an ab like: ab command: ab -r -n 1000 -c 2 http://localhost:8080/ I get a segfault pretty fast. But with Apache recompiled to generate the dump I'm not able to reproduce it ------------------------------------------------------------------------ [2013-12-13 16:25:36] raja dot govindharaj at bjss dot com We used mistakenly two caches (opcache and apc) that cacused the apache crash when do graceful or restart. I have now disabled apc which solved the problem. ------------------------------------------------------------------------ [2013-12-13 09:28:50] raja dot govindharaj at bjss dot com We are also experiencing the same seg fault and nasty error. The segfaults occurs when do graceful restart Apache. We use the same version of PHP (5.4.19), CentOS 6.4 and OpCache 7.0.2. It occurs always though disable fast shutdown option (opcache.fast_shutdown=0). /httpd graceful - crashed Apache. ------------------------------------------------------------------------ [2013-10-16 10:40:56] arjen at react dot com Looks like this also happens under php-fpm (5.5.4): #0 0x000000000060dff7 in ?? () #1 0x000000000060e1fb in ?? () #2 0x0000000000642f2e in zend_hash_destroy () #3 0x0000000000625bc3 in ?? () #4 0x0000000000635412 in ?? () #5 0x00000000005d5c1d in php_request_shutdown () #6 0x0000000000426724 in ?? () #7 0x00007f406e548bc5 in __libc_start_main () from /usr/lib/libc.so.6 #8 0x0000000000427505 in _start () ------------------------------------------------------------------------ [2013-09-09 10:24:38] ole dot skudsvik at gmail dot com What i've found is that if you disable opcache.fast_shutdown in php.ini we do not experience any crashes. The documentation of opcache.fast_shutdown states: If enabled, a fast shutdown sequence is used for the accelerated code The fast shutdown sequence doesn't free each allocated block, but lets the Zend Engine Memory Manager do the work. I've im also now able to reproduce the segfault by doing the following: <?php opcache_reset(); Zend\Mvc\Application::init(blah).run(); ?> What i think happen here is: * We call opcache_reset() which triggers a free() on all opcache allocated resources. * We start the Zend application. * When the Zend application shuts down Zend tries to free the already free'ed memory since it's told to do so by the fast_shutdown flag. Ofcourse Zend should check if the memory is already free'd before trying to free it, but it seems it does not ? ------------------------------------------------------------------------ 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=65590 -- Edit this bug report at https://bugs.php.net/bug.php?id=65590&edit=1