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:
---------------
<?php
$variable = 2.0;
function testGlobal()
{
global $variable;
var_dump($variable);
}
testGlobal();
$variable += 1;
testGlobal();
$variable = "Changing to string.";
testGlobal();
?>
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
