Bug #65338 [Fbk]: Enabling both php_opcache and php_wincache AVs on shutdown
Edit report at https://bugs.php.net/bug.php?id=65338edit=1 ID: 65338 Updated by: a...@php.net 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: @Eric, yes, one can only enable/disable it in whole. What i meant is making it more flexible, disabling opcache and string pool, but not affecting other features like user cache. Like APCu, but there opcode cache was just cut out. Splitting the functionality into configurable pieces would require some effort of course. And that was actually the idea you reflected at the earlier post. As neither opcode cache nor interned strings aren't required for user cache. Previous Comments: [2013-07-29 18:30:01] erics...@php.net @a...@php.net Wincache.ocenabled is PHP_INI_ALL, meaning that the Wincache opcode cache can be enabled/disabled by script or by user.ini. This is the same for Zend Opcache opcache.enabled and APC apc.enabled. To support this, the interned strings have to be hooked at module load time. This is how all three opcode caches implement the hooking of interned strings. [2013-07-27 16:56:28] phpdev at ehrhardt dot nl @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. [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 :) 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=65338edit=1
Bug #65338 [Fbk]: Enabling both php_opcache and php_wincache AVs on shutdown
Edit report at https://bugs.php.net/bug.php?id=65338edit=1 ID: 65338 Updated by: a...@php.net 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: @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 :) Previous Comments: [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=revisionrevision=330859 [2013-07-26 21:07:09] me at laurinkeithdavis dot com I can confirm that this patch works as well. https://bugs.php.net/bug.php?id=65247 [2013-07-26 16:48:39] phpdev at ehrhardt dot nl @Anatol: Xinchen ran into the same problem while combining APC usercache with OPcache opcode cache. See http://svn.php.net/viewvc?view=revisionrevision=330859 He solved it by disabling interned_string. @Eric: I can confirm your patch works. Tested it as well under X86 as X64. [2013-07-26 16:04:36] erics...@php.net a...@php.net said What is the catch/sense of using both at the same time? Wincache provides a file cache, session cache, user property cache as well as an opcode cache. Further, it's possible to disable the opcode cache. On PHP5.5, we (Wincache support folks) expect customers to enable the Zend opcache (because it's in 'core', and probably does more optimizing than Wincache does), but continue to use Wincache for file, session and user cache. 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=65338edit=1
Bug #65338 [Fbk]: Enabling both php_opcache and php_wincache AVs on shutdown
Edit report at https://bugs.php.net/bug.php?id=65338edit=1 ID: 65338 Updated by: a...@php.net 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: 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. Previous Comments: [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=revisionrevision=330859 [2013-07-26 21:07:09] me at laurinkeithdavis dot com I can confirm that this patch works as well. https://bugs.php.net/bug.php?id=65247 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=65338edit=1
Bug #65338 [Fbk]: Enabling both php_opcache and php_wincache AVs on shutdown
Edit report at https://bugs.php.net/bug.php?id=65338edit=1 ID: 65338 Updated by: paj...@php.net 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: +Assigned To:dmitry Block user comment: N Private report: N New Comment: Agreed,should be applied in php-src and github repos. Previous Comments: [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=revisionrevision=330859 [2013-07-26 21:07:09] me at laurinkeithdavis dot com I can confirm that this patch works as well. https://bugs.php.net/bug.php?id=65247 [2013-07-26 16:48:39] phpdev at ehrhardt dot nl @Anatol: Xinchen ran into the same problem while combining APC usercache with OPcache opcode cache. See http://svn.php.net/viewvc?view=revisionrevision=330859 He solved it by disabling interned_string. @Eric: I can confirm your patch works. Tested it as well under X86 as X64. [2013-07-26 16:04:36] erics...@php.net a...@php.net said What is the catch/sense of using both at the same time? Wincache provides a file cache, session cache, user property cache as well as an opcode cache. Further, it's possible to disable the opcode cache. On PHP5.5, we (Wincache support folks) expect customers to enable the Zend opcache (because it's in 'core', and probably does more optimizing than Wincache does), but continue to use Wincache for file, session and user cache. [2013-07-26 10:58:23] a...@php.net What is the catch/sense of using both at the same time? Both are opcaches and can cross each other in many other hooks, most important replacing zend_compile_file. It's beyond what happens, wincache replaces zend_compile_file with its own, followed by opcache replacing it with its own. Or vice versa. What happens to user trying to use the first loaded module then? 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=65338edit=1
