fast_shutdown = 1 crashes

[jswinghammer]

Running PHP 5.4.20 and zend op cache 7.0.2. When we enable fast_shutdown = 1 and the number of objects created on a page gets large (more than 1900 or so objects) we see 500 errors occur during random parts of the page. This wasn't happening on all the pages but it was always correlated to the total number of objects that were getting instantiated on the page. Below that 1900 count I wasn't seeing the error at all. Turning off the fast_shutdown setting resolved the 500 errors.

For example the HTML output will look normal enough until the footer and then we'll see the standard apache 500 error text appear. Nothing gets logged in this case and no core files are created. I'm happy to answer any questions or give you more information.

[laruence]

can you test with the latest snapshot of opcache?
and are you able to show us a backtrace?

[jswinghammer]

I can. The crash has produced no backtraces in the past. If it started I
would be happy to send it.

On Fri, Nov 1, 2013 at 2:29 AM, Xinchen Hui notifications@github.comwrote:

can you test with the latest snapshot of opcache?
and are you able to show us a backtrace?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/146#issuecomment-27549798
.

[jswinghammer]

As I said in the bug we are using 7.0.2. Is there something newer you can
point me to?

On Fri, Nov 1, 2013 at 7:09 AM, Jon Swinghammer <
jonathan.swinghammer@gmail.com> wrote:

I can. The crash has produced no backtraces in the past. If it started I
would be happy to send it.

On Fri, Nov 1, 2013 at 2:29 AM, Xinchen Hui notifications@github.comwrote:

can you test with the latest snapshot of opcache?
and are you able to show us a backtrace?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/146#issuecomment-27549798
.

[laruence]

https://github.com/zendtech/ZendOptimizerPlus/archive/master.zip

[matthew-muscat]

Seeing the same issue here on 7.0.2, fast shutdown enabled causes a 500 error, this occurs for us on large processing operations (ie: 5000+ products being exported in Magento)

[warn] [client xxx.xxx.xx.xx] (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server
[error] [client xxx.xxx.xx.xx] Premature end of script headers: index.php

I'll test out the latest version once i've got time to load it into a staging environment.

[arjenschol]

I'm also experiencing crashes/segfaults with fast_shutdown=1. Crash is constantly reproducible, but not in a simple testcase, only in a set of tests also performing a lot of HTTP requests to the same server. Crashes at the same place. With fast_shutdown disabled, the crashes are gone.

PHP 5.5.12 and latest opcache.

#0 0x000000000060ceb7 in ?? ()
No symbol table info available.
#1 0x000000000060d0cc in ?? ()
No symbol table info available.
#2 0x0000000000633080 in zend_stack_destroy ()
No symbol table info available.
#3 0x0000000000634315 in ?? ()
No symbol table info available.
#4 0x00000000005d4a7d in php_request_shutdown ()
No symbol table info available.
#5 0x0000000000424ed4 in ?? ()
No symbol table info available.
#6 0x00007fe9d7550000 in __libc_start_main () from /usr/lib/libc.so.6
No symbol table info available.
#7 0x0000000000425cb3 in _start ()
No symbol table info available.

[AdamWill]

I'm seeing something similar with OwnCloud 7 running on PHP 5.5.17: owncloud/core#9885 . Trying to access OC often (>50% of the time) crashes PHP in the opcache. Disabling fast_shutdown works around the problem.

[AdamWill]

note: i've been tracking my instance of this similar issue at https://bugs.php.net/bug.php?id=67687 and owncloud/core#9885 . Basically it looks like it's happening when OwnCloud edits its config.php file and calls opcache_reset() - see the bugs.php.net report for more details.

[hugochinchilla]

I was having trouble with segmentation faults after upgrading to php 5.5.23, setting fast_shutdown = 0 seems to solve the issue.

More infor here: https://bugs.php.net/bug.php?id=69190

[pixelchutes]

Recently migrated a few projects on a legacy server (still running on PHP 5.3, using ZendOpcache 7.0.5 to PHP 5.6 with built-in ZendOpcache 7.0.6-dev.

On occasion, started seeing random 500 errors or "zend_mm_heap corrupted" warning in the error logs that were never experienced before.

Re-tuning the opcache configuration (increasing max_accelerated_files, and setting opcache.fast_shutdown=0) appears to have resolved the issues so far.

[scottsb]

@pixelchutes: it looks like you might be running into this issue (which may or may not be related to what this ancient issue discusses): https://bugs.php.net/bug.php?id=65590

[pixelchutes]

Thanks for linking that here @scottsb! I did come across Bug 65590 during my review, definitely seems related. However, I've seen very few zend_mm_heap corrupted errors in comparison to other symptoms I ended up posting in more detail here: #187 (comment)

As long as there are no "corrupt" worker processes (see above link), everything appears to function as expected. Still trying to identify the source of the impacted php-fpm worker(s), and whether or not it's OPcache related.

[duzun]

Is it still the case in PHP 7+ ?

[mfn]

From https://www.php.net/manual/en/opcache.configuration.php#ini.opcache.fast-shutdown

This directive has been removed in PHP 7.2.0. A variant of the fast shutdown sequence has been integrated into PHP and will be automatically used if possible.

So maybe this whole thing doens't apply anymore for PHP >= 7.2

[melroy89]

This issue should be closed now.

[dstogov]

opcache.fast_shutdown was removed in PHP-7.2