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 ?

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 ()

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.

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.

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

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.

I am currently experiencing this same behavior on PHP 5.5.30 (ondrej/php5 PPA on Ubuntu 14.04) and the latest official Ubuntu 14.04 package (5.5.9+....). I do not have APC installed obviously but am using ZendOPcache (v7.0.6-dev and 7.0.4 respectively). It occurs with or without opcache.fast_shutdown.

Another server running the exact same code (load balanced) with PHP 5.4.45 (dotdeb.org package) does not exhibit this issue.

I disabled Zend OPcache in favor of XCache and the error disappeared.

Sorry, I spoke too soon, setting opcache.enabled = 0 did not resolve the problem. It seems that since there is a large delay after restart before it happens that it might be related to Apache 2.4 MaxConnectionsPerChild which I have set to 2000.

Is this still an issue with any of the actively supported PHP
versions[1]?

[1] <https://www.php.net/supported-versions.php>

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.