Bug #66597 [Fbk->NoF]: OPCACHE BUG

From: Date: Tue, 30 Dec 2014 10:42:22 +0000
Subject: Bug #66597 [Fbk->NoF]: OPCACHE BUG
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-189460@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=66597&edit=1

 ID:               66597
 Updated by:       php-bugs@lists.php.net
 Reported by:      edu_1721 at hotmail dot com
 Summary:          OPCACHE BUG
-Status:           Feedback
+Status:           No Feedback
 Type:             Bug
 Package:          opcache
 Operating System: CENTOS 6.5 32 BITS
 PHP Version:      5.5.8
 Private report:   N

 New Comment:

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.


Previous Comments:
------------------------------------------------------------------------
[2014-02-04 16:12:52] daniel at blodan dot se

I just got a core dump in cli with opcache activated, disabling opcache made the core dumping go
away, might be related:
https://bugs.php.net/bug.php?id=66642

------------------------------------------------------------------------
[2014-02-03 16:14:52] rasmus@php.net

Try setting opcache.optimization_level=0 in your ini and see if that changes things. If it does,
then this has already been fixed.

------------------------------------------------------------------------
[2014-02-03 06:38:05] krakjoe@php.net

The problem is that this description doesn't give us a starting place to work with;
there's no logical pathway to what you describe, both requests infact do serve the same ops
from shm, the first request is no different to the second, logically.

If there are lots of dependencies then gist/git is an option, but it's preferable for you to
try to reduce the problem to it's simplest possible form and use that code in a bug report.

A bad gateway message is indicative of a crashed php-fpm process, it's probably possible to
attach to a php-fpm worker and hit it till it crashes, you can then at least provide a backtrace and
or coredump, this would also give us a starting place.

------------------------------------------------------------------------
[2014-02-02 15:51:35] daniel at blodan dot se

Having the same issue on FreeBSD with nginx 1.4.4 and php-fpm 5.5.8 with opcache, reverting back to
5.5.6 solves the issue.

Unfortunately I can't give a simple reproduceable script, the websites run through frameworks
such as laravel and codeigniter.

All I can tell is that the first request to a non-compiled script results in a Bad Gateway response,
the second request works as its supposed to. So it seems that opcache returns something different
the request it compiles the files than when it's reading from its cache.

------------------------------------------------------------------------
[2014-01-28 19:06:07] krakjoe@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.



------------------------------------------------------------------------


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=66597


--
Edit this bug report at https://bugs.php.net/bug.php?id=66597&edit=1


Thread (7 messages)

« previous php.bugs (#189460) next »