Edit report at https://bugs.php.net/bug.php?id=66460&edit=1
ID: 66460
User updated by: spam2 at rhsoft dot net
Reported by: spam2 at rhsoft dot net
Summary: PHP 5.5.7 and 5.5.8 horrible unstable
Status: Closed
Type: Bug
Package: opcache
Operating System: Linux
PHP Version: 5.5.8
Assigned To: rasmus
Block user comment: N
Private report: N
New Comment:
> And you still haven't answered the question of whether
> setting it to 0 affects what you are seeing
https://github.com/zendtech/ZendOptimizerPlus/archive/master.zip
built standalone with "opcache.optimization_level = 0" does *not* crash
with default settings *it does crash* as with 5.5.7 / 5.5.8 sources
[root@asterisk:~]$ rpm -q --filesbypkg php-opcache
php-opcache /usr/lib64/php/modules/opcache.so
what i *really* do not understand is that the first here happened is set the bugreport to
"closed" - based on waht?
Previous Comments:
------------------------------------------------------------------------
[2014-01-16 02:56:00] phpdev at ehrhardt dot nl
I found the 'guilty' commit by bisecting the commits since 5.5.6. Then I found out that
Superfish was the package that triggered the bug. After that Dmitry applied a fix, which solved my
problems with Superfish. You can never be sure the fix covered all possible cases. That is why I
asked you to mix the two tarballs.
The info you are supplying now will not give Rasmus or Dmitry enough to determine what goes wrong.
And simply saying that all commits since 5.5.6 have to be reverted is a no-go either. There were
bugs in 5.5.6. You did not notice them, but others did. These bugs have to be fixed and the only way
to do that is applying similar fixes as the commits since then. As long as you cannot pinpoint what
goes wrong in your case, the devs can never be sure what they can and what they can't change.
------------------------------------------------------------------------
[2014-01-16 02:34:30] rasmus@php.net
> > because many people run with the optimization_level set to 0
> i doubt that because it's not default
Nevertheless, it is true. It is certainly why I never noticed it on any of my production boxes.
And you still haven't answered the question of whether setting it to 0 affects what you are
seeing. I know you didn't change it and that it worked in 5.5.6, but it would still help us
narrow it down and determine if it is the same bug.
------------------------------------------------------------------------
[2014-01-16 02:29:12] spam2 at rhsoft dot net
> Sounds like a different bug
pretty sure because on https://bugs.php.net/bug.php?id=66474 you said
solved by https://github.com/zendtech/ZendOptimizerPlus/archive/master.zip
and that is why any change after 5.5.6 in ext/opcache should be reverted
because not a single bug there could have the same bad impact as the "fixes"
------------------------------------------------------------------------
[2014-01-16 02:25:28] phpdev at ehrhardt dot nl
Sounds like a different bug. The only way to make sure is, really, trying the block_pass.c from the
5.5.6 tarball and the other files from the 5.5.8 tarball.
------------------------------------------------------------------------
[2014-01-16 02:17:10] spam2 at rhsoft dot net
> Did you ever try the block_pass.c from the 5.5.6 tarball
> and the other files from the 5.5.8 tarball?
no, only 5.5.6 opcache on 5.5.8 source and head opcache on 5.5.8 source
both have the same segfault-behavior obviously introduced in 5.5.7
i noticed this a few times before christmas on local machines but
not predictable to reproduce and calling the same page 100000 times
with a benchmark after restart httpd may not trigegr a single segfault
due a lot of updates in system libraries in the first front i was unsure
if there was something broken, starting with 2014/01/07 i upgraded servers
from Fedora 18/PHP 5.4 to Fedora 19 PHP/5.5, tests looked fine and after
teh first low-trafficserver the segfaults in the apache-errorlog started
heavily, so i downgraded to PHP 5.5.6 quickly
the day before i found something with such sgefaults in context of
"zend.enable_gc", disabled it and for a short time it looked OK
finally after 5.5.8 had the same issues and no predictable way to
reproduce i started playing around with configuration, one of the
first things was to disable opcache, not a single segfault
since downgrade to 5.4 would have been way too much work i tried
the 5.5.6 opcache because i had PHP 5.5 over months on my development
machines and faced the problem not until december
so the only thing i currently can say is that in case of the Linux
kernel *any* commit to opcache after 5.5.6 would have been *reverted*
completly
> because many people run with the optimization_level set to 0
i doubt that because it's not default
------------------------------------------------------------------------
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=66460
--
Edit this bug report at https://bugs.php.net/bug.php?id=66460&edit=1