Edit report at https://bugs.php.net/bug.php?id=65338&edit=1
ID: 65338
Comment by: phpdev at ehrhardt dot nl
Reported by: erics...@php.net
Summary: Enabling both php_opcache and php_wincache AVs on
shutdown
Status: Feedback
Type: Bug
Package: Reproducible crash
Operating System: Windows
PHP Version: 5.5.1
Assigned To: dmitry
Block user comment: N
Private report: N
New Comment:
@Anatol: which older versions? PHP 5.4.x users that run into this problem
should upgrade to 5.4.18, the moment that is released with this patch. Making
special arrangements for older 5.4.x users would be a waste of developer
resources IMO.
And PHP 5.3 (or lower) users do not run into this, because interned_string was
introduced in the Zend engine for 5.4.
Previous Comments:
------------------------------------------------------------------------
[2013-07-27 15:25:39] a...@php.net
Jan, I meant exactly that, there still will be some users on versions lower
than
5.4.17 or which is the current. The question is just whether it's worth the
effort
to be aware of that.
------------------------------------------------------------------------
[2013-07-27 12:18:07] phpdev at ehrhardt dot nl
@Anatol: there is no need to disable interned strings in extensions for older
PHP-versions if you backport the patch. I do not think I have the karma to put
a patch here, but this is the backport for PHP 5.4:
http://x32.elijst.nl/zend_interned_strings_shutdown_AV.patch
Maybe except for some line numbers it is literally the same patch.
------------------------------------------------------------------------
[2013-07-27 08:30:25] a...@php.net
@Eric ok, so the catch is to use the wincache with disabled opcode cache.
Whereby
interned strings are neither opcode cache nor any other functionality. The
patch
would solve it only for newer PHP versions, maybe it should be possible to
disable
interned strings explicitly in wincache/opcache, maybe per ini? That would
solve
it also for users with older PHP without TS.
@Jan that's obvious now where people start to mix the cache engines :)
------------------------------------------------------------------------
[2013-07-27 05:02:11] paj...@php.net
Agreed,should be applied in php-src and
github repos.
------------------------------------------------------------------------
[2013-07-27 01:27:59] phpdev at ehrhardt dot nl
The problem is so obvious, that I am surprised it did not com to surface
earlier. And the patch is elegant: do not assume interned_strings_start
is still the same, but free only the memory that you owned at startup.
In fact, the patch should be backported to PHP 5.4 as well. I do not
have a use case for X86, but I ran into the same problem woth PHP 5.4
X64. I know this is no official version, but as an illustration of the
problem it still is useful.
Compare these two builds:
https://dl.dropboxusercontent.com/u/8954372/php-5.4.17-nts-Win32-VC9-x64.zip
https://dl.dropboxusercontent.com/u/8954372/php-5.4.17-nts-Win32-VC9-x64_patched.zip
Try the unpatched one first. Put this in your php.ini:
extension=php_wincache.dll
zend_extension=ext/php_opcache.dll
zend_opcache.memory_consumption=128
zend_opcache.interned_strings_buffer=8
zend_opcache.max_accelerated_files=4000
zend_opcache.revalidate_freq=60
zend_opcache.fast_shutdown=1
zend_opcache.enable_cli=1
wincache.ocenabled=0
wincache.fcenabled=0
wincache.ucachesize=768
wincache.enablecli=1
session.savehandler=wincache
Then run from the commandline in your php-directory:
php-cgi.exe -m
php-cgi will crash after showing the loaded modules. Debugging with VC9
gave this result: http://x32.elijst.nl/zendfree.png
Quite another breakpoint as in the PHP 5.5 example, but with the same
cause: freeing memory you do not own.
In the patched build I backported Eric's patch for zend_string.c to PHP
5.4. Result: no crash anymore.
A last remark: i do not think the problem is Windows specific. This is
exectly the same problem, but with the combination of opcache and apc:
http://svn.php.net/viewvc?view=revision&revision=330859
------------------------------------------------------------------------
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=65338
--
Edit this bug report at https://bugs.php.net/bug.php?id=65338&edit=1
