Skip to content
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

Open
jswinghammer opened this Issue Oct 31, 2013 · 13 comments

Comments

Projects
None yet
9 participants
@jswinghammer
Copy link

jswinghammer commented Oct 31, 2013

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

This comment has been minimized.

Copy link
Member

laruence commented Nov 1, 2013

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

@jswinghammer

This comment has been minimized.

Copy link
Author

jswinghammer commented Nov 1, 2013

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

This comment has been minimized.

Copy link
Author

jswinghammer commented Nov 1, 2013

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

This comment has been minimized.

@matthew-muscat

This comment has been minimized.

Copy link

matthew-muscat commented Nov 21, 2013

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

This comment has been minimized.

Copy link

arjenschol commented May 13, 2014

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

This comment has been minimized.

Copy link

AdamWill commented Jul 24, 2014

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

This comment has been minimized.

Copy link

AdamWill commented Jul 26, 2014

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

This comment has been minimized.

Copy link

hugochinchilla commented Apr 15, 2015

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

This comment has been minimized.

Copy link

pixelchutes commented Jun 8, 2016

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

This comment has been minimized.

Copy link

scottsb commented Jun 22, 2016

@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

This comment has been minimized.

Copy link

pixelchutes commented Jun 22, 2016

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

This comment has been minimized.

Copy link

duzun commented Nov 6, 2018

Is it still the case in PHP 7+ ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.