[PHP-BUG] Bug #65338 [NEW]: Enabling both php_opcache and php_wincache AVs on shutdown
From: ericsten Operating system: Windows PHP version: 5.5.1 Package: Reproducible crash Bug Type: Bug Bug description:Enabling both php_opcache and php_wincache AVs on shutdown Description: If both php_wincache.dll and php_opcache.dll are enabled, and if they are both enabled for CLI, any script leads to an AV at process exit. The call stack indicates that the AV is in zend_interned_strings_dtor, on the following line: free(CG(interned_strings_start)); This is because the value in CG(interned_strings_start) is pointing at the chunk of memory provided by php_wincache.dll for its interned strings. I'm seeing in the debugger that on process startup, the modules are loaded in the order: 1. php_wincache.dll 2. php_opcache.dll And on shutdown, they're terminated in exactly the same order. This causes a problem, because both modules set the CG(interned_strings_start) based upon the value it copied during startup. In this case, php_opcache.dll copied the value that php_wincache.dll set when it started up. So, the last value put back into CG(interned_strings_start) on shutdown was php_wincache's interned strings buffer. php_wincache.dll allocated the interned strings block using (zend's) pemalloc(), but the address for CG(interned_strings_start) is an offset within the allocation, so free() thinks the heap is corrupted. Question: Why are modules terminated in the same order they were initialized? For modules that do 'hooking' of functions or memory, it seems the "unhooking" should happen in reverse order. php.ini settings: zend_extension=php_opcache.dll extension=php_wincache.dll [opcache] opcache.enable=1 opcache.enable_cli=1 [wincache] wincache.enablecli=1 wincache.ocenabled=0 Test script: --- Expected result: No AV on shutdown -- Edit bug report at https://bugs.php.net/bug.php?id=65338&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65338&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65338&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65338&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65338&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65338&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65338&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65338&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65338&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65338&r=support Expected behavior: https://bugs.php.net/fix.php?id=65338&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65338&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65338&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65338&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65338&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65338&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65338&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65338&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65338&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65338&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65338&r=mysqlcfg
Bug #65338 [PATCH]: Enabling both php_opcache and php_wincache AVs on shutdown
Edit report at https://bugs.php.net/bug.php?id=65338&edit=1 ID: 65338 Patch added by: erics...@php.net Reported by:erics...@php.net Summary:Enabling both php_opcache and php_wincache AVs on shutdown Status: Open Type: Bug Package:Reproducible crash Operating System: Windows PHP Version:5.5.1 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: zend_interned_strings_shutdown_AV Revision: 1374773456 URL: https://bugs.php.net/patch-display.php?bug=65338&patch=zend_interned_strings_shutdown_AV&revision=1374773456 Previous Comments: [2013-07-25 17:30:31] erics...@php.net Description: If both php_wincache.dll and php_opcache.dll are enabled, and if they are both enabled for CLI, any script leads to an AV at process exit. The call stack indicates that the AV is in zend_interned_strings_dtor, on the following line: free(CG(interned_strings_start)); This is because the value in CG(interned_strings_start) is pointing at the chunk of memory provided by php_wincache.dll for its interned strings. I'm seeing in the debugger that on process startup, the modules are loaded in the order: 1. php_wincache.dll 2. php_opcache.dll And on shutdown, they're terminated in exactly the same order. This causes a problem, because both modules set the CG(interned_strings_start) based upon the value it copied during startup. In this case, php_opcache.dll copied the value that php_wincache.dll set when it started up. So, the last value put back into CG(interned_strings_start) on shutdown was php_wincache's interned strings buffer. php_wincache.dll allocated the interned strings block using (zend's) pemalloc(), but the address for CG(interned_strings_start) is an offset within the allocation, so free() thinks the heap is corrupted. Question: Why are modules terminated in the same order they were initialized? For modules that do 'hooking' of functions or memory, it seems the "unhooking" should happen in reverse order. php.ini settings: zend_extension=php_opcache.dll extension=php_wincache.dll [opcache] opcache.enable=1 opcache.enable_cli=1 [wincache] wincache.enablecli=1 wincache.ocenabled=0 Test script: --- Expected result: No AV on shutdown -- Edit this bug report at https://bugs.php.net/bug.php?id=65338&edit=1
Bug #65338 [Com]: Enabling both php_opcache and php_wincache AVs on shutdown
Edit report at https://bugs.php.net/bug.php?id=65338&edit=1 ID: 65338 Comment by: erics...@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 Block user comment: N Private report: N New Comment: 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. Previous Comments: [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? [2013-07-26 07:01:23] a...@php.net Related To: Bug #65247 ---- [2013-07-25 17:30:56] erics...@php.net The following patch has been added/updated: Patch Name: zend_interned_strings_shutdown_AV Revision: 1374773456 URL: https://bugs.php.net/patch-display.php?bug=65338&patch=zend_interned_strings_shutdown_AV&revision=1374773456 -------- [2013-07-25 17:30:31] erics...@php.net Description: If both php_wincache.dll and php_opcache.dll are enabled, and if they are both enabled for CLI, any script leads to an AV at process exit. The call stack indicates that the AV is in zend_interned_strings_dtor, on the following line: free(CG(interned_strings_start)); This is because the value in CG(interned_strings_start) is pointing at the chunk of memory provided by php_wincache.dll for its interned strings. I'm seeing in the debugger that on process startup, the modules are loaded in the order: 1. php_wincache.dll 2. php_opcache.dll And on shutdown, they're terminated in exactly the same order. This causes a problem, because both modules set the CG(interned_strings_start) based upon the value it copied during startup. In this case, php_opcache.dll copied the value that php_wincache.dll set when it started up. So, the last value put back into CG(interned_strings_start) on shutdown was php_wincache's interned strings buffer. php_wincache.dll allocated the interned strings block using (zend's) pemalloc(), but the address for CG(interned_strings_start) is an offset within the allocation, so free() thinks the heap is corrupted. Question: Why are modules terminated in the same order they were initialized? For modules that do 'hooking' of functions or memory, it seems the "unhooking" should happen in reverse order. php.ini settings: zend_extension=php_opcache.dll extension=php_wincache.dll [opcache] opcache.enable=1 opcache.enable_cli=1 [wincache] wincache.enablecli=1 wincache.ocenabled=0 Test script: --- Expected result: No AV on shutdown -- Edit this bug report at https://bugs.php.net/bug.php?id=65338&edit=1
Bug #65338 [Com]: Enabling both php_opcache and php_wincache AVs on shutdown
Edit report at https://bugs.php.net/bug.php?id=65338&edit=1 ID: 65338 Comment by: erics...@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: @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. Previous Comments: [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 :) [2013-07-27 05:02:11] paj...@php.net Agreed,should be applied in php-src and github repos. 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
