Edit report at https://bugs.php.net/bug.php?id=66460&edit=1
ID: 66460
Updated by: rasmus@php.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:
Well, others reported the base issue fixed in this bug. It appears you have a separate problem, but
"horrible unstable" is not a useful bug report. If you can get segfaults, get a back
trace. Narrow it down to a specific bit of code and open a report we can do something with.
Previous Comments:
------------------------------------------------------------------------
[2014-01-16 11:55:15] spam2 at rhsoft dot net
> 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?
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
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