|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #65338 Enabling both php_opcache and php_wincache AVs on shutdown
Submitted: 2013-07-25 17:30 UTC Modified: 2013-07-30 13:39 UTC
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: Assigned: dmitry (profile)
Status: Closed Package: Reproducible crash
PHP Version: 5.5.1 OS: Windows
Private report: No CVE-ID: None
 [2013-07-25 17:30 UTC]
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:


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.


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:


Test script:
$variable = 2.0;
function testGlobal()
    global $variable;
$variable += 1;
$variable = "Changing to string.";

Expected result:
No AV on shutdown


zend_interned_strings_shutdown_AV (last revision 2013-07-25 17:30 UTC by

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-07-25 17:30 UTC]
The following patch has been added/updated:

Patch Name: zend_interned_strings_shutdown_AV
Revision:   1374773456
 [2013-07-26 10:58 UTC]
-Status: Open +Status: Feedback
 [2013-07-26 10:58 UTC]
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 16:04 UTC] 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 16:48 UTC] phpdev at ehrhardt dot nl
@Anatol: Xinchen ran into the same problem while combining APC usercache with OPcache opcode cache. See
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 21:07 UTC] me at laurinkeithdavis dot com
I can confirm that this patch works as well.
 [2013-07-27 01:27 UTC] 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:

Try the unpatched one first. Put this in your php.ini:




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:
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:
 [2013-07-27 05:02 UTC]
-Assigned To: +Assigned To: dmitry
 [2013-07-27 05:02 UTC]
Agreed,should be applied in php-src and 
github repos.
 [2013-07-27 08:30 UTC]
@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 12:18 UTC] 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:

Maybe except for some line numbers it is literally the same patch.
 [2013-07-27 15:25 UTC]
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 16:56 UTC] 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-29 18:30 UTC]

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-30 07:06 UTC]
@Eric, yes, one can only enable/disable it in whole. What i meant is making it 
flexible, disabling opcache and string pool, but not affecting other features 
user cache.

Like APCu, but there opcode cache was just cut out. Splitting the functionality 
configurable pieces would require some effort of course. And that was actually 
idea you reflected at the earlier post. As neither opcode cache nor interned 
aren't required for user cache.
 [2013-07-30 13:36 UTC]
Automatic comment on behalf of
Log: Fixed bug #65338 (Enabling both php_opcache and php_wincache AVs on shutdown).
 [2013-07-30 13:36 UTC]
-Status: Feedback +Status: Closed
 [2013-07-30 13:39 UTC]
The fix for this bug has been committed.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at

 For Windows:
Thank you for the report, and for helping us make PHP better.

 [2013-07-30 15:13 UTC] phpdev at ehrhardt dot nl
@dmitry: grabbed the snapshot from;a=summary and compiled it. No crash anymore!

Nitpicking: typo OPcahce in the NEWS diff.

And curious: why did you decide to fix the problem by changing OPcache? Is not there a fundamental problem in zend_string.c that it sometimes frees memory while interned_strings_start has been changed? Or am I completely missing the point?
 [2013-11-17 09:30 UTC]
Automatic comment on behalf of
Log: Fixed bug #65338 (Enabling both php_opcache and php_wincache AVs on shutdown).
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Jul 19 21:01:28 2024 UTC