New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fast_shutdown = 1 crashes #146
Comments
can you test with the latest snapshot of opcache? |
I can. The crash has produced no backtraces in the past. If it started I On Fri, Nov 1, 2013 at 2:29 AM, Xinchen Hui notifications@github.comwrote:
|
As I said in the bug we are using 7.0.2. Is there something newer you can On Fri, Nov 1, 2013 at 7:09 AM, Jon Swinghammer <
|
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)
I'll test out the latest version once i've got time to load it into a staging environment. |
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 ?? () |
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. |
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. |
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 |
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 |
@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 |
Thanks for linking that here @scottsb! I did come across Bug 65590 during my review, definitely seems related. However, I've seen very few 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. |
Is it still the case in PHP 7+ ? |
From https://www.php.net/manual/en/opcache.configuration.php#ini.opcache.fast-shutdown
So maybe this whole thing doens't apply anymore for PHP >= 7.2 |
This issue should be closed now. |
|
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.
The text was updated successfully, but these errors were encountered: